9 ms·

Because CUDA was a fantastic API from the beginning, and it took forever for OpenCL to catch up (has it even really caught up?). I remember writing CUDA parall

Because CUDA was a fantastic API from the beginning, and it took forever for OpenCL to catch up (has it even really caught up?). I remember writing CUDA parallelized C++ code in 2010 and it was a piece of cake.

mort96 4y ago
Alright, in that case I suppose the trade-off was clear: use a nice API and lock yourself in, or use a less nice API and be able to use any hardware. Nvidia cards becoming less competitive over time is in any case a very predictable outcome. Sounds like the ML community made a trade-off, and this is the downside of that trade-off.
- meragrin_ 4y ago
  > Sounds like the ML community made a trade-off Nope, AMD never gave them a choice.
binarymax 4y ago
@mort96 I've reached the thread depth and can't reply directly - but it's not just a case of a nice API. I don't even think it was possible to use alternative hardware and SDKs for consumer GPGPUs for deep learning when the field was taking off. It was not so much a choice but the only viable option. Has Nvidia taken advantage of their position? Absolutely. But don't fault the ML community when there was nothing else available.
- mort96 4y ago
  HN limits how fast you can reply. I think it's to reduce flame wars and force people to take some time to cool off if things get heated :) Just wait a few minutes and it lets you respond. OpenCL has existed for about as long as CUDA, and can be used on GPUs from any of the major manufacturers. What makes OpenCL so unsuitable for ML that the ML community just had to use CUDA?
  - fny 4y ago
    CUDA came first and OpenCL tends to perform worse.
  - latency-guy2 4y ago
    CUDA was just plain better back in the day, more feature robust, and more features in general. Much simpler to pick up as well, especially at the time with what tools and libraries we were forced to use NVIDIA also partnered up very quickly with many big players in the game, the sales people went to work, but they had the technological feats to back it up. After that, it's the network effect.
  - jjoonathan 4y ago
    AMD's OpenCL implementation and tooling were really, really rough. Lots of hard lockups, memory leaks, and forum threads ending in the person with the question giving up and switching to team green. I followed this path eventually, too. The breaking point happened when I had spent an entire day trying to get a bit of OpenCL working, thinking that I was at fault, but then I tried running it on a NVidia box, hoping to get a more descriptive error, but the code Just Worked. NVidia's OpenCL implementation was better than AMD's, and not by a small amount. CUDA was better still. I realized I had thrown away $n0000 of my own time chasing a $n00 discount on the AMD card (controlling for perf). Never again. Now that AMD has money, hopefully they have fixed their stack, but I'm still in "once bitten, twice shy" mode. I want to see someone else in my field using AMD on tasks I care about before I try team red again.
    - dotnet00 4y ago
      Same experience here, as recently as with AMD's 5000 series GPUs. As far as I'm aware their OpenCL stack is still terrible, they're focusing mainly on HIP and ROCm, but it too has terrible consumer side support and an update model that makes it essentially useless as a long term investment. They include device code for every supported GPU, so they have to drop support for older cards to keep the binaries reasonably sized. In contrast, CUDA compiles down to a device agnostic intermediate language so they can support the same code on several generations of hardware, limited only by the CUDA feature level available on the hardware. AMD still has a long way to go for now. Both in terms of 'primary' functionality like supported hardware and compilers and 'secondary' functionality like detailed profiling and debugging tools.
- uup 4y ago
  You can reply directly if you click on the timestamp of the comment you want to reply to.

mort96 4y ago

Alright, in that case I suppose the trade-off was clear: use a nice API and lock yourself in, or use a less nice API and be able to use any hardware. Nvidia cards becoming less competitive over time is in any case a very predictable outcome. Sounds like the ML community made a trade-off, and this is the downside of that trade-off.

meragrin_ 4y ago
> Sounds like the ML community made a trade-off Nope, AMD never gave them a choice.

binarymax 4y ago

@mort96 I've reached the thread depth and can't reply directly - but it's not just a case of a nice API. I don't even think it was possible to use alternative hardware and SDKs for consumer GPGPUs for deep learning when the field was taking off. It was not so much a choice but the only viable option. Has Nvidia taken advantage of their position? Absolutely. But don't fault the ML community when there was nothing else available.

mort96 4y ago
HN limits how fast you can reply. I think it's to reduce flame wars and force people to take some time to cool off if things get heated :) Just wait a few minutes and it lets you respond. OpenCL has existed for about as long as CUDA, and can be used on GPUs from any of the major manufacturers. What makes OpenCL so unsuitable for ML that the ML community just had to use CUDA?
- fny 4y ago
  CUDA came first and OpenCL tends to perform worse.
- latency-guy2 4y ago
  CUDA was just plain better back in the day, more feature robust, and more features in general. Much simpler to pick up as well, especially at the time with what tools and libraries we were forced to use NVIDIA also partnered up very quickly with many big players in the game, the sales people went to work, but they had the technological feats to back it up. After that, it's the network effect.
- jjoonathan 4y ago
  AMD's OpenCL implementation and tooling were really, really rough. Lots of hard lockups, memory leaks, and forum threads ending in the person with the question giving up and switching to team green. I followed this path eventually, too. The breaking point happened when I had spent an entire day trying to get a bit of OpenCL working, thinking that I was at fault, but then I tried running it on a NVidia box, hoping to get a more descriptive error, but the code Just Worked. NVidia's OpenCL implementation was better than AMD's, and not by a small amount. CUDA was better still. I realized I had thrown away $n0000 of my own time chasing a $n00 discount on the AMD card (controlling for perf). Never again. Now that AMD has money, hopefully they have fixed their stack, but I'm still in "once bitten, twice shy" mode. I want to see someone else in my field using AMD on tasks I care about before I try team red again.
  - dotnet00 4y ago
    Same experience here, as recently as with AMD's 5000 series GPUs. As far as I'm aware their OpenCL stack is still terrible, they're focusing mainly on HIP and ROCm, but it too has terrible consumer side support and an update model that makes it essentially useless as a long term investment. They include device code for every supported GPU, so they have to drop support for older cards to keep the binaries reasonably sized. In contrast, CUDA compiles down to a device agnostic intermediate language so they can support the same code on several generations of hardware, limited only by the CUDA feature level available on the hardware. AMD still has a long way to go for now. Both in terms of 'primary' functionality like supported hardware and compilers and 'secondary' functionality like detailed profiling and debugging tools.
uup 4y ago
You can reply directly if you click on the timestamp of the comment you want to reply to.