Hacker News Reader

Comment by antoineMoPa | Hacker News Reader

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.

View on HN

From 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.

But did you ever care about openness, vendor lock-in and portability? Most people in the world can't afford 600$ Nvidia GPUs.

> 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.

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.

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.

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

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.

Reply on news.ycombinator.com