11 ms·

It makes me sad that CUDA is more popular than OpenCL. I would be willing to sacrifice some performance for portability, openness and avoiding vendor lock-in.

twtw 8y ago
From https://news.ycombinator.com/item?id=18197988 https://news.ycombinator.com/item?id=18197988: > MIOpen[1] is a step in this direction but still causes the VEGA 64 + MIOpen to be 60% of the performance of a 1080 Ti + CuDNN based on benchmarks we've conducted internally at Lambda. Let that soak in for a second: the VEGA 64 (15TFLOPS theoretical peak) is 0.6x of a 1080 Ti (11.3TFLOPS theoretical peak). MIOpen is very far behind CuDNN. That performance penalty is a bit too steep for me. Vega64 should be 1.3x perf compared to 1080ti, but instead it is 0.6x. 50% lower performance is quite a sacrifice.
- antoineMoPa 8y ago
  But did you ever care about openness, vendor lock-in and portability? Most people in the world can't afford 600$ Nvidia GPUs.
  - twtw 8y ago
    > Most people in the world can't afford 600$ Nvidia GPUs. Ok? I'm not what your point is here - most people can't afford a $600 amd gpu either. If you can't get a $600 gpu, buy a cheaper gpu - gtx 1060 is $250 or gtx 960 is $50. Performance costs a premium, and that is just how is is. It would be great if we lived in a world where you could buy a Titan v for $1, but in the real world valuable things cost more money, and that unfortunately means not everyone can buy them.
    - deleted 8y ago
      [deleted]
    - deleted 8y ago
      [deleted]
  - nl 8y ago
    I care about openness a lot. I also care about performance. It's too bad AMD doesn't put in the effort NVidia does to make sure computation on their GPUs is as easy to do as it is on NVidias.
pjmlp 8y ago
I never cared to play around OpenCL, because they were stuck with C only mentality, plus the stone age idea from GLSL that I should somehow read text files, compile and link them programmatically, and a pat on the back for debugging. CUDA right from the start supported C, C++, Fortran, with a bytecode format for other compiler backends, and a nice debugging experience. Obvious which one would gain the hearts of developers that have moved beyond C. It took Khronos up to OpenCL 2.0 to fix this, by then it was too late. Even on mobile devices, Google created their own C99 dialect (Renderscript) instead of adopting OpenCL.
swerner 8y ago
I don't think performance is the achilles heel of OpenCL. There are other problems that I have when working with: The implementations ended up becoming a "write once, debug everywhere" ecosystem. Making the compiler a part of the driver meant that OpenCL kernels that worked on platform A wouldn't even compile on platform B. SPIR-V should have been part of OpenCL from version 1.0. Profiling OpenCL kernels is a stumbling block too - IMHO, you shouldn't ship a toolkit without a profiler and claim it's intended for HPC. IEE 754 compliance should also have been part of 1.0 and not an afterthought. Without it, it's harder to verify that your kernel works correctly, since it's permitted to deliver different results than a C reference implementation. With CUDA, at least you're guaranteed* that your code that runs on your CUDA equipped machine, also runs on any other machine that supports CUDA - regardless of OS, regardless of GPU. With OpenCL, not so much. * Within the same restrictions as CPU code - instruction set, RAM and compiler bugs.
profquail 8y ago
It may be possible for the code in these libraries to be made portable using the ROCm HIP compiler: https://github.com/ROCm-Developer-Tools/HIP https://github.com/ROCm-Developer-Tools/HIP

twtw 8y ago

From https://news.ycombinator.com/item?id=18197988 https://news.ycombinator.com/item?id=18197988: > MIOpen[1] is a step in this direction but still causes the VEGA 64 + MIOpen to be 60% of the performance of a 1080 Ti + CuDNN based on benchmarks we've conducted internally at Lambda. Let that soak in for a second: the VEGA 64 (15TFLOPS theoretical peak) is 0.6x of a 1080 Ti (11.3TFLOPS theoretical peak). MIOpen is very far behind CuDNN. That performance penalty is a bit too steep for me. Vega64 should be 1.3x perf compared to 1080ti, but instead it is 0.6x. 50% lower performance is quite a sacrifice.

antoineMoPa 8y ago
But did you ever care about openness, vendor lock-in and portability? Most people in the world can't afford 600$ Nvidia GPUs.
- twtw 8y ago
  > Most people in the world can't afford 600$ Nvidia GPUs. Ok? I'm not what your point is here - most people can't afford a $600 amd gpu either. If you can't get a $600 gpu, buy a cheaper gpu - gtx 1060 is $250 or gtx 960 is $50. Performance costs a premium, and that is just how is is. It would be great if we lived in a world where you could buy a Titan v for $1, but in the real world valuable things cost more money, and that unfortunately means not everyone can buy them.
  - deleted 8y ago
    [deleted]
  - deleted 8y ago
    [deleted]
- nl 8y ago
  I care about openness a lot. I also care about performance. It's too bad AMD doesn't put in the effort NVidia does to make sure computation on their GPUs is as easy to do as it is on NVidias.

pjmlp 8y ago

I never cared to play around OpenCL, because they were stuck with C only mentality, plus the stone age idea from GLSL that I should somehow read text files, compile and link them programmatically, and a pat on the back for debugging. CUDA right from the start supported C, C++, Fortran, with a bytecode format for other compiler backends, and a nice debugging experience. Obvious which one would gain the hearts of developers that have moved beyond C. It took Khronos up to OpenCL 2.0 to fix this, by then it was too late. Even on mobile devices, Google created their own C99 dialect (Renderscript) instead of adopting OpenCL.

swerner 8y ago

I don't think performance is the achilles heel of OpenCL. There are other problems that I have when working with: The implementations ended up becoming a "write once, debug everywhere" ecosystem. Making the compiler a part of the driver meant that OpenCL kernels that worked on platform A wouldn't even compile on platform B. SPIR-V should have been part of OpenCL from version 1.0. Profiling OpenCL kernels is a stumbling block too - IMHO, you shouldn't ship a toolkit without a profiler and claim it's intended for HPC. IEE 754 compliance should also have been part of 1.0 and not an afterthought. Without it, it's harder to verify that your kernel works correctly, since it's permitted to deliver different results than a C reference implementation. With CUDA, at least you're guaranteed* that your code that runs on your CUDA equipped machine, also runs on any other machine that supports CUDA - regardless of OS, regardless of GPU. With OpenCL, not so much. * Within the same restrictions as CPU code - instruction set, RAM and compiler bugs.

profquail 8y ago

It may be possible for the code in these libraries to be made portable using the ROCm HIP compiler: https://github.com/ROCm-Developer-Tools/HIP https://github.com/ROCm-Developer-Tools/HIP