5 ms·

Please, please, please stop basing free software projects on proprietary libraries like CUDA.

by yarrel 11y ago

fabulist 11y ago
Please understand that proprietary software isn't an enemy that must be routed out, and that developing good software (using the right tools for the job) is usually more important (to the developer) than developing software with no proprietary dependencies.
- joe_the_user 11y ago
  The companies that give away proprietary libraries that developers come to depend on essentially do act as an "enemy within" - you never know when they'll decide that their original reason to give away the library didn't give them enough profits and they are going start charging for future licenses, change the interface, drop support or whatever. Didn't Twitter pull the plug on a company using one of its private interfaces just a few days ago (slightly different but not entirely different). Cuda looks several orders of magnitude easier than OpenCl but Cuda versus opencl is just not simply a "best tool" question for an ongoing project. There's every reason to wish to remove proprietary libraries whether that's possible or not.
robert_foss 11y ago
I would say that there are very good reasons for hesitating when thinking about adopting software that is reliant on proprietary software. Like vendor lock in. This project however appears to support OpenCL which is not proprietary.
pizza 11y ago
What should I learn instead, if I have an nVidia GPU?
- joe_the_user 11y ago
  OpenCl targets nVidia GPUs also, at least according to the documentation. The main problem is OpenCL seems an order of magnitude more complex than CUDA. To be honest, Cuda seems semi-portable just because (according to documentation and tutorials I've read) you do little more than allocate memory, tag functions, write loops and the compiler figures out the rest. OpenCL seems to demand everything be specified in gruesome detail whether in the c or the c++ version. Also, the latest pdf-pamphlet of the Khronos Group on opencl 1.2 just says they're "exploring" an open source implementation of the spec, which doesn't encourage one to imagine the spec as available. Edit: Researching this, it seems that the CUDA compiler actually has been integrated into clang/llvm. An open spec with open compiler seems as open as one can get with software - it only targets NVidia but you can just complain Linux was proprietary when it originally only targeted Intel. https://research.nvidia.com/news/nvidia-contributes-cuda-compiler-open-source-community https://research.nvidia.com/news/nvidia-contributes-cuda-com...
  - slizard 11y ago
    > The main problem is OpenCL seems an order of magnitude more complex than CUDA. Do you have any experience to back that up with? I've worked with both and I know that there are areas where your "order of magnitude" (which BTW I'd like to see on paper, quantified) does hold up, e.g. dev tools, but in general your claim is simply false. > To be honest, Cuda seems semi-portable just because (according to documentation and tutorials I've read) you do little more than allocate memory, tag functions, write loops and the compiler figures out the rest. Nonsense, you're likely confusing OpenACC with CUDA, the CUDA runtime API is in many cases considerably more simple than OpenCL, but it requires a compiler, and frankly often times is screams rushed design/implementation. In contrast, the CUDA driver API is quite similar to OpenCL. ...and BTW OpenACC is "open" only on paper and in fact it is a very divisive move that has created conflicts, polarized the community, and undermined collaboration between multiple parties (in particular with the OpenMP proponents). > Also, the latest pdf-pamphlet of the Khronos Group on opencl 1.2 just says they're "exploring" an open source implementation of the spec, which doesn't encourage one to imagine the spec as available. The latest spec is 2.0 FYI; can you explain my how on earth does one's imagination go astray so badly to believe that just because there is no reference implementation one would consider the spec "not available". Don't get me started with the examples of standards that exist without an official reference implementation. > Edit: Researching this, it seems that the CUDA compiler actually has been integrated into clang/llvm. An open spec with open compiler seems as open as one can get with software - it only targets NVidia but you can just complain Linux was proprietary when it originally only targeted Intel. BS. Show me the "open spec of CUDA". Even if one did exist, good luck trying to influence the design of it if you're not an big oil company, Google, Audi or GM. Also, try to use the CUDA name without having to pay a ton of money. And you seem to forget that the "open compiler" does not actually generate byte-code (that's done by the propritary JIT compiler) and even if did, you still nee NVIDIA's proprietary driver to run it.
- slizard 11y ago
  Depends what you want to gain? You want to do scientific computing? Interested in mobile platforms? Or just curious about GPUs? Without knowing the answer to that, I won't attempt to go into more details, but will give two examples: * If you want to have transferable knowledge (e.g. to be able to jump into mobile development on ARM), choose OpenCL. * If you're curious to learn and try stuff out mostly to get a taste of GPU computing, consider using CUDA (as it has better dev tools), but if you find it fun/useful, do consider switching to OpenCL.
chrisbennet 11y ago
CUDA is designed to help NVidia to sell more chips so I don't see it as a big risk. While it is all well and good to hold certain beliefs [people shouldn't eat meat, use cars, whatever], it also a valid to believe there is nothing wrong with using proprietary, for profit software. Personally I believe that exchanging money for something of value is fine.
- slizard 11y ago
  > CUDA is designed to help NVidia to sell more chips so I don't see it as a big risk. Don't you see it as a risk to marry your project to a proprietary API of a company that actively and intentionally cripples their implementation of the standard for no other apparent reason but to hold back progress of OpenCL and essentially ensure vendor lock-in and create a disadvantageous situation for competitors relying on the aforementioned standards?
  - chrisbennet 11y ago
    Yes, I see it as a risk but for me, it's an acceptable risk. I make choices and take risks all the time but for pragmatic, (not religious)reasons.

Please, please, please stop basing free software projects on proprietary libraries like CUDA.

by yarrel 11y ago

Please, please, please stop basing free software projects on proprietary libraries like CUDA.

Please understand that proprietary software isn't an enemy that must be routed out, and that developing good software (using the right tools for the job) is usually more important (to the developer) than developing software with no proprietary dependencies.

joe_the_user 11y ago
The companies that give away proprietary libraries that developers come to depend on essentially do act as an "enemy within" - you never know when they'll decide that their original reason to give away the library didn't give them enough profits and they are going start charging for future licenses, change the interface, drop support or whatever. Didn't Twitter pull the plug on a company using one of its private interfaces just a few days ago (slightly different but not entirely different). Cuda looks several orders of magnitude easier than OpenCl but Cuda versus opencl is just not simply a "best tool" question for an ongoing project. There's every reason to wish to remove proprietary libraries whether that's possible or not.

robert_foss 11y ago

I would say that there are very good reasons for hesitating when thinking about adopting software that is reliant on proprietary software. Like vendor lock in. This project however appears to support OpenCL which is not proprietary.

pizza 11y ago

What should I learn instead, if I have an nVidia GPU?

joe_the_user 11y ago
OpenCl targets nVidia GPUs also, at least according to the documentation. The main problem is OpenCL seems an order of magnitude more complex than CUDA. To be honest, Cuda seems semi-portable just because (according to documentation and tutorials I've read) you do little more than allocate memory, tag functions, write loops and the compiler figures out the rest. OpenCL seems to demand everything be specified in gruesome detail whether in the c or the c++ version. Also, the latest pdf-pamphlet of the Khronos Group on opencl 1.2 just says they're "exploring" an open source implementation of the spec, which doesn't encourage one to imagine the spec as available. Edit: Researching this, it seems that the CUDA compiler actually has been integrated into clang/llvm. An open spec with open compiler seems as open as one can get with software - it only targets NVidia but you can just complain Linux was proprietary when it originally only targeted Intel. https://research.nvidia.com/news/nvidia-contributes-cuda-compiler-open-source-community https://research.nvidia.com/news/nvidia-contributes-cuda-com...
- slizard 11y ago
  > The main problem is OpenCL seems an order of magnitude more complex than CUDA. Do you have any experience to back that up with? I've worked with both and I know that there are areas where your "order of magnitude" (which BTW I'd like to see on paper, quantified) does hold up, e.g. dev tools, but in general your claim is simply false. > To be honest, Cuda seems semi-portable just because (according to documentation and tutorials I've read) you do little more than allocate memory, tag functions, write loops and the compiler figures out the rest. Nonsense, you're likely confusing OpenACC with CUDA, the CUDA runtime API is in many cases considerably more simple than OpenCL, but it requires a compiler, and frankly often times is screams rushed design/implementation. In contrast, the CUDA driver API is quite similar to OpenCL. ...and BTW OpenACC is "open" only on paper and in fact it is a very divisive move that has created conflicts, polarized the community, and undermined collaboration between multiple parties (in particular with the OpenMP proponents). > Also, the latest pdf-pamphlet of the Khronos Group on opencl 1.2 just says they're "exploring" an open source implementation of the spec, which doesn't encourage one to imagine the spec as available. The latest spec is 2.0 FYI; can you explain my how on earth does one's imagination go astray so badly to believe that just because there is no reference implementation one would consider the spec "not available". Don't get me started with the examples of standards that exist without an official reference implementation. > Edit: Researching this, it seems that the CUDA compiler actually has been integrated into clang/llvm. An open spec with open compiler seems as open as one can get with software - it only targets NVidia but you can just complain Linux was proprietary when it originally only targeted Intel. BS. Show me the "open spec of CUDA". Even if one did exist, good luck trying to influence the design of it if you're not an big oil company, Google, Audi or GM. Also, try to use the CUDA name without having to pay a ton of money. And you seem to forget that the "open compiler" does not actually generate byte-code (that's done by the propritary JIT compiler) and even if did, you still nee NVIDIA's proprietary driver to run it.
slizard 11y ago
Depends what you want to gain? You want to do scientific computing? Interested in mobile platforms? Or just curious about GPUs? Without knowing the answer to that, I won't attempt to go into more details, but will give two examples: * If you want to have transferable knowledge (e.g. to be able to jump into mobile development on ARM), choose OpenCL. * If you're curious to learn and try stuff out mostly to get a taste of GPU computing, consider using CUDA (as it has better dev tools), but if you find it fun/useful, do consider switching to OpenCL.

chrisbennet 11y ago

CUDA is designed to help NVidia to sell more chips so I don't see it as a big risk. While it is all well and good to hold certain beliefs [people shouldn't eat meat, use cars, whatever], it also a valid to believe there is nothing wrong with using proprietary, for profit software. Personally I believe that exchanging money for something of value is fine.

slizard 11y ago
> CUDA is designed to help NVidia to sell more chips so I don't see it as a big risk. Don't you see it as a risk to marry your project to a proprietary API of a company that actively and intentionally cripples their implementation of the standard for no other apparent reason but to hold back progress of OpenCL and essentially ensure vendor lock-in and create a disadvantageous situation for competitors relying on the aforementioned standards?
- chrisbennet 11y ago
  Yes, I see it as a risk but for me, it's an acceptable risk. I make choices and take risks all the time but for pragmatic, (not religious)reasons.