6 ms·

Will OpenCL help displace GPGPU? (2012)

28 points by luu 11y ago

DiabloD3 11y ago
That article is largely a trainwreck. Yes, OpenCL is an API and shader language for GPGPU usage. Yes, it is a competitor to CUDA. No, CUDA is not the majority of GPGPU usage (although in 2012, 3+ years ago, this may have been true depending on who you spoke to), OpenCL now is. No, CUDA and OpenCL competing is not an issue, as Nvidia is a founding member of Khronos's OpenCL committee, and Nvidia uses a merged compiler backend for all their shaders (including OpenCL and CUDA); neither API will produce better optimized binaries than the other on Nvidia hardware. Yes, there are OpenCL implementations for CPUs: AMD and Nvidia's implementations both can be executed on x86 CPUs (useful for lock step full program debugging without needing to deal with the async nature of GPUs), Intel has one for x86, IBM has one for PPC/PPC64/Power. Yes, there are OpenCL implementations for DSPs. That was already a thing in 2012. Sony/IBM has one for Cell SPEs. Yes, GPUs are in fact highly parallel DSPs. No, since 2012, Parallela nor P2012 ever took off. No, OpenCL cannot displace GPGPU because that is like saying Electric will displace the Car. No, instead, we'll make cars that run on electricity instead of gasoline, ie, we'll be changing APIs to more universally supported ones. Is GPGPU dying? 'Yes.' What is killing it? The march of technology into making EVERYTHING generic processing: floating point used to be a specialized application requiring an optional co-processor: it is now part of the CPU; SIMD used to be part of specialized DSPs, that, too, is now part of the CPU, and that part of the CPU becomes more complex every other generation or so; GPGPUs were merged on-die a few generations back and natively speak to the CPU's memory controller and socket bus as if they were just another core. And merging GPGPUs on-die isn't even new, if we view them as just specialized highly parallel DSPs: MIPS and ARM SoCs have done this for like the past decade by including communications and audio processing DSPs in the package or on-die. So, just like the FPU, and SIMD, GPGPUs as highly parallel DSPs are being merged into the CPU. And, as a side note, you know what this looks like from the other side, a CPU becoming a highly parallel DSP? Intel's Xeon Phi series. And, as another side note, since it is now a given that CPUs need to be able to do embarrassingly parallel tasks optimizedly, Intel is now tackling the fact that QPI is not scalable across a CCNUMA cluster like AMD's Hypertransport is, and is now moving to embed their Infiniband variant onto CPU and Phi dies, for native 40/100gbit on-die. There are already Xeon E5/E7s slated to have this on a post-LGA-2011-3 socket. Disclaimer: I wrote DiabloMiner, that popular GPU Bitcoin miner everyone used until ASICs took over.
- revelation 11y ago
  It seems a large amount of GPGPU nowadays is deep learning, and OpenCL is nowhere to be seen. CUDA or rather cuDNN is where it's at.
  - DiabloD3 11y ago
    cuDNN is just a library written by Nvidia for Nvidia GPUs. AMD maintains a OpenCL version of Caffe (another popular framework for DNN), and apparently other DNN frameworks also have or will have OpenCL support.
    - varelse 11y ago
      And the OpenCL incarnations all have wretched performance relative to CUDA. Why doesn't someone do something about that?
      - DiabloD3 11y ago
        All the malfunctioning OpenCL code I've ever seen is because they were former CUDA users and simply didn't know how to properly use OpenCL (a common example, they use a workgroup size of less than 64 (aka a warp or a wavefront), which is also unoptimized on modern Nvidia hardware too). And as I said above, there is no performance difference between OpenCL and CUDA on Nvidia hardware; although, I should probably amend that with "as long as both versions of the code are sane."
        varelse 11y ago
        Are you kidding me? Exploiting the native warp-width is a 50-100% performance improvement when appropriate. Not querying the warp-width OTOH is amateur hour coding.
        DiabloD3 11y ago
        The problem is a lot of CUDA and OpenCL programmers are not programmers at all, but are amateurs with STEM degrees. They think programming is easy because, surely, all you're doing is typing a few words into a text file, how hard could it be? I wish I was telling a joke, I've met a lot of "programmers" from academia that don't care if their code is horrible, or worse yet, returns a wrong answer during edge cases, they just want it to compile error free and produce results. This intersects with the popular HN opinion of "if you're going to publish a scientific paper, you must also publish the exact code that processed your results, too."
SuperComputing 11y ago
No. It won't.

28 points by luu 11y ago

That article is largely a trainwreck. Yes, OpenCL is an API and shader language for GPGPU usage. Yes, it is a competitor to CUDA. No, CUDA is not the majority of GPGPU usage (although in 2012, 3+ years ago, this may have been true depending on who you spoke to), OpenCL now is. No, CUDA and OpenCL competing is not an issue, as Nvidia is a founding member of Khronos's OpenCL committee, and Nvidia uses a merged compiler backend for all their shaders (including OpenCL and CUDA); neither API will produce better optimized binaries than the other on Nvidia hardware. Yes, there are OpenCL implementations for CPUs: AMD and Nvidia's implementations both can be executed on x86 CPUs (useful for lock step full program debugging without needing to deal with the async nature of GPUs), Intel has one for x86, IBM has one for PPC/PPC64/Power. Yes, there are OpenCL implementations for DSPs. That was already a thing in 2012. Sony/IBM has one for Cell SPEs. Yes, GPUs are in fact highly parallel DSPs. No, since 2012, Parallela nor P2012 ever took off. No, OpenCL cannot displace GPGPU because that is like saying Electric will displace the Car. No, instead, we'll make cars that run on electricity instead of gasoline, ie, we'll be changing APIs to more universally supported ones. Is GPGPU dying? 'Yes.' What is killing it? The march of technology into making EVERYTHING generic processing: floating point used to be a specialized application requiring an optional co-processor: it is now part of the CPU; SIMD used to be part of specialized DSPs, that, too, is now part of the CPU, and that part of the CPU becomes more complex every other generation or so; GPGPUs were merged on-die a few generations back and natively speak to the CPU's memory controller and socket bus as if they were just another core. And merging GPGPUs on-die isn't even new, if we view them as just specialized highly parallel DSPs: MIPS and ARM SoCs have done this for like the past decade by including communications and audio processing DSPs in the package or on-die. So, just like the FPU, and SIMD, GPGPUs as highly parallel DSPs are being merged into the CPU. And, as a side note, you know what this looks like from the other side, a CPU becoming a highly parallel DSP? Intel's Xeon Phi series. And, as another side note, since it is now a given that CPUs need to be able to do embarrassingly parallel tasks optimizedly, Intel is now tackling the fact that QPI is not scalable across a CCNUMA cluster like AMD's Hypertransport is, and is now moving to embed their Infiniband variant onto CPU and Phi dies, for native 40/100gbit on-die. There are already Xeon E5/E7s slated to have this on a post-LGA-2011-3 socket. Disclaimer: I wrote DiabloMiner, that popular GPU Bitcoin miner everyone used until ASICs took over.

revelation 11y ago
It seems a large amount of GPGPU nowadays is deep learning, and OpenCL is nowhere to be seen. CUDA or rather cuDNN is where it's at.
- DiabloD3 11y ago
  cuDNN is just a library written by Nvidia for Nvidia GPUs. AMD maintains a OpenCL version of Caffe (another popular framework for DNN), and apparently other DNN frameworks also have or will have OpenCL support.
  - varelse 11y ago
    And the OpenCL incarnations all have wretched performance relative to CUDA. Why doesn't someone do something about that?
    - DiabloD3 11y ago
      All the malfunctioning OpenCL code I've ever seen is because they were former CUDA users and simply didn't know how to properly use OpenCL (a common example, they use a workgroup size of less than 64 (aka a warp or a wavefront), which is also unoptimized on modern Nvidia hardware too). And as I said above, there is no performance difference between OpenCL and CUDA on Nvidia hardware; although, I should probably amend that with "as long as both versions of the code are sane."
      - varelse 11y ago
        Are you kidding me? Exploiting the native warp-width is a 50-100% performance improvement when appropriate. Not querying the warp-width OTOH is amateur hour coding.
        DiabloD3 11y ago
        The problem is a lot of CUDA and OpenCL programmers are not programmers at all, but are amateurs with STEM degrees. They think programming is easy because, surely, all you're doing is typing a few words into a text file, how hard could it be? I wish I was telling a joke, I've met a lot of "programmers" from academia that don't care if their code is horrible, or worse yet, returns a wrong answer during edge cases, they just want it to compile error free and produce results. This intersects with the popular HN opinion of "if you're going to publish a scientific paper, you must also publish the exact code that processed your results, too."

SuperComputing 11y ago

No. It won't.