5 ms·

so how does one go about proposing additions or changes to CUDA? ironically, i've been able to get more performance from OpenCL than CUDA (mostly due in part t

by foxhill 13y ago

so how does one go about proposing additions or changes to CUDA? ironically, i've been able to get more performance from OpenCL than CUDA (mostly due in part to OpenCL's dual-source model, it allows me to compile runtime constants into kernels). CUDA is no more "optimised" than OpenCL. it's the same compiler that generates kernels. enqueueRead/Write calls end up being cudaMemcpy, etc.

goldenkey 13y ago
You can compile runtime constants into CUDA too. CUDA has both a driver api AND the standard C toolkit. CUDA is a lot more optimized than OpenCL when you use it right. Many of the library functions perform better than there OpenCL equivalents or take different types. Having used both, I've got to say that OpenCL is craptastic compared to CUDA. One big example is the fact that you can't set a kernel-wide global in OpenCL, you have to pass it to the kernel every time as a buffer. In CUDA you can lookup the global by symbol, and set it, and it remains persistent. That means the CUDA kernel func will have a slightly smaller stack size from not having all these craptastic persistent args passed to the kernel every time. Also, instead of dereferencing a pointer that is passed as a kernel arg, you are directly using the global, again, code optimized. You haven't used CUDA enough probably. I understand how on the surface they appear similar. But wholly, CUDA is better thought out.
- foxhill 13y ago
  it's not the standard programming model in CUDA. the library functions compile down to the same PTX, it's the exactly the same toolchain wether you use nvcc or clBuildProgram - if you could provide an example indicating otherwise, i'd very much like to see it. you most certainly can set a kernel-wide global in OpenCL, and it does not need to be a buffer object. and you don't need to re-set it between kernel invocations (this would be true even if it were a buffer object). OpenCL is certainly verbose, but honestly, given that you may have multiple implementations of it on the same machine, i don't really see how it could be done any simpler (at least from the C API perspective). i use CUDA and OpenCL every working day. it is literally what i am employed to do.
  - goldenkey 13y ago
    Standard programming model? Please stop. You have two options with CUDA, no one is tying your hands in a knot, NVidia doesn't have a committee setting standards on which of their 2 flavors of toolkit you need to use. You are so biased it hurts. Considering you use OpenCL at work every day it would help all the hackers here if you don't spread mistruths. There are no statics in opencl unless they are in constant memory and set in the program source. And we both know constant memory is quite limited and this fact would require you to interpolate your data into a byte array to sprintf it into source. There are no persistent global in opencl. You must pass all your globals to your kernel. We both know setKernelArg is persistent across kernel calls- but who cares? In CUDA you don't need an argument and you don't need to dereference it either. Way better. http://www.khronos.org/message_boards/showthread.php/6437-Global-variables-in-OpenCL http://www.khronos.org/message_boards/showthread.php/6437-Gl...
    - foxhill 13y ago
      as in, it's not how any tutorial or walk through i've ever seen has tried to teach the user about CUDA, it's not something nvidia talk about primarily in their documentation of the language. if it's so common, why isn't it being used in rust? please, continue to make fallacious statements about me and what i think. i really don't care. regardless, there are three (not two) programming models in CUDA - high level (CUBLAS/FFT), CUDA runtime, and the driver API. constant memory is 64k on an M2050, a GPU from 3 years ago. if you want to set more than 16 thousand floating point constants.. well, you probably want to put that in main memory. i use OpenCL and CUDA, every day. and sorry for misunderstanding what you were saying, but really? you think passing in an argument is such a hassle? yes, setKernelArg is persistent across calls - so i'm confused why you're saying you don't care? it does exactly what you've been complaining it can't do (and, yes, it requires an extra kernel argument, oh my). you've been constantly bashing OpenCL - nothing more than a document, the contents of which are decided by a committee of people, none of whom are myself - implicitly praising CUDA, and you call me biased? you don't even know what i think about either of them.
      - goldenkey 13y ago
gnarbarian 13y ago
I wouldn't say that cuda is more "optimized" but last I checked it does have better support for pointers, recursion, spawning new threads from inside of existing threads etc. This allows for more sophisticated data structures and algorithms that are impossible to replicate exactly in openCL. A Barnes-Hut simulation [1] for example is way tougher to build in OpenCL. [1] http://en.wikipedia.org/wiki/Barnes%E2%80%93Hut_simulation http://en.wikipedia.org/wiki/Barnes%E2%80%93Hut_simulation
- foxhill 13y ago
  i'm not sure what you mean about better support for pointers. dynamic parallelism is in OpenCL now.
  - gnarbarian 13y ago
    I remember looking into this a couple months ago and using pointers was still strongly discouraged due to massive performance impacts.

by foxhill 13y ago

goldenkey 13y ago

You can compile runtime constants into CUDA too. CUDA has both a driver api AND the standard C toolkit. CUDA is a lot more optimized than OpenCL when you use it right. Many of the library functions perform better than there OpenCL equivalents or take different types. Having used both, I've got to say that OpenCL is craptastic compared to CUDA. One big example is the fact that you can't set a kernel-wide global in OpenCL, you have to pass it to the kernel every time as a buffer. In CUDA you can lookup the global by symbol, and set it, and it remains persistent. That means the CUDA kernel func will have a slightly smaller stack size from not having all these craptastic persistent args passed to the kernel every time. Also, instead of dereferencing a pointer that is passed as a kernel arg, you are directly using the global, again, code optimized. You haven't used CUDA enough probably. I understand how on the surface they appear similar. But wholly, CUDA is better thought out.

foxhill 13y ago
it's not the standard programming model in CUDA. the library functions compile down to the same PTX, it's the exactly the same toolchain wether you use nvcc or clBuildProgram - if you could provide an example indicating otherwise, i'd very much like to see it. you most certainly can set a kernel-wide global in OpenCL, and it does not need to be a buffer object. and you don't need to re-set it between kernel invocations (this would be true even if it were a buffer object). OpenCL is certainly verbose, but honestly, given that you may have multiple implementations of it on the same machine, i don't really see how it could be done any simpler (at least from the C API perspective). i use CUDA and OpenCL every working day. it is literally what i am employed to do.
- goldenkey 13y ago
  Standard programming model? Please stop. You have two options with CUDA, no one is tying your hands in a knot, NVidia doesn't have a committee setting standards on which of their 2 flavors of toolkit you need to use. You are so biased it hurts. Considering you use OpenCL at work every day it would help all the hackers here if you don't spread mistruths. There are no statics in opencl unless they are in constant memory and set in the program source. And we both know constant memory is quite limited and this fact would require you to interpolate your data into a byte array to sprintf it into source. There are no persistent global in opencl. You must pass all your globals to your kernel. We both know setKernelArg is persistent across kernel calls- but who cares? In CUDA you don't need an argument and you don't need to dereference it either. Way better. http://www.khronos.org/message_boards/showthread.php/6437-Global-variables-in-OpenCL http://www.khronos.org/message_boards/showthread.php/6437-Gl...
  - foxhill 13y ago
    as in, it's not how any tutorial or walk through i've ever seen has tried to teach the user about CUDA, it's not something nvidia talk about primarily in their documentation of the language. if it's so common, why isn't it being used in rust? please, continue to make fallacious statements about me and what i think. i really don't care. regardless, there are three (not two) programming models in CUDA - high level (CUBLAS/FFT), CUDA runtime, and the driver API. constant memory is 64k on an M2050, a GPU from 3 years ago. if you want to set more than 16 thousand floating point constants.. well, you probably want to put that in main memory. i use OpenCL and CUDA, every day. and sorry for misunderstanding what you were saying, but really? you think passing in an argument is such a hassle? yes, setKernelArg is persistent across calls - so i'm confused why you're saying you don't care? it does exactly what you've been complaining it can't do (and, yes, it requires an extra kernel argument, oh my). you've been constantly bashing OpenCL - nothing more than a document, the contents of which are decided by a committee of people, none of whom are myself - implicitly praising CUDA, and you call me biased? you don't even know what i think about either of them.
    - goldenkey 13y ago

gnarbarian 13y ago

I wouldn't say that cuda is more "optimized" but last I checked it does have better support for pointers, recursion, spawning new threads from inside of existing threads etc. This allows for more sophisticated data structures and algorithms that are impossible to replicate exactly in openCL. A Barnes-Hut simulation [1] for example is way tougher to build in OpenCL. [1] http://en.wikipedia.org/wiki/Barnes%E2%80%93Hut_simulation http://en.wikipedia.org/wiki/Barnes%E2%80%93Hut_simulation

foxhill 13y ago
i'm not sure what you mean about better support for pointers. dynamic parallelism is in OpenCL now.
- gnarbarian 13y ago
  I remember looking into this a couple months ago and using pointers was still strongly discouraged due to massive performance impacts.