As the two major programming frameworks for GPU computing, OpenCL and CUDA have been competing for mindshare in the developer community for the past few years. Until recently, CUDA has attracted most of the attention from developers, especially in the high performance computing realm. But OpenCL software has now matured to the point where HPC practitioners are taking a second look.

Both OpenCL and CUDA provide a general-purpose model for data parallelism as well as low-level access to hardware, but only OpenCL provides an open, industry-standard framework. As such, it has garnered support from nearly all processor manufacturers including AMD, Intel, and NVIDIA, as well as others that serve the mobile and embedded computing markets. As a result, applications developed in OpenCL are now portable across a variety of GPUs and CPUs.

Although OpenCL 1.0 was introduced in December 2008, just a year and a half after the NVIDIA launched its first version of CUDA, OpenCL still trails CUDA in popularity by a wide margin, especially with regard to HPC. That is mostly due to a concerted effort by NVIDIA to establish CUDA as the dominant programming framework for GPU application development in this realm..

AMD has been the most vocal booster of OpenCL technology for technical computing, but it’s lack of a competitive product set for high-end GPU computing has muted that message. Thus far, OpenCL usage has been mostly relegated to client-side computing, especially for mobile platforms, which have increasingly incorporated GPU silicon into their designs. Apple, who initially developed OpenCL before handing it off to the open-standard Khronos Group, was instrumental in getting the technology off the ground.

The knock on OpenCL for HPC users has been lack of maturity, which has resulted in low performance, compared to CUDA. There is also the perception that support from the principle HPC chipmakers (Intel, AMD and NVIDIA) would be less than enthusiastic, at least for their high-end processors. In many ways, that’s still true, given that NVIDIA is devoting most of its attention to its home-grown CUDA software, while Intel seems to have settled on its own parallel programming frameworks, mainly Cilk Plus and Threading Building Blocks.

AMD though, continues to champion OpenCL, and some of their more recent compiler and library releases have improved performance considerably. In fact, Kyle Spafford, from the Future Technology Group at Oak Ridge National Lab (ORNL), has been benchmarking the two technologies for some time and is now convinced that OpenCL performance is now on par with that of CUDA. He recently presented his findings at Georgia Tech’s Keeneland Workshop.

Spafford’s ran ORNL’s Scalable Heterogeneous Computing Benchmark Suite (SHOC) that has been optimized for both CUDA and OpenCL, and found that OpenCL can match CUDA performance on most of the basic math kernels. He also found that OpenCL’s performance on some kernels, like SGEMM, has increased 10-fold since 2009. The one code that CUDA still has a significant performance advantage is that of the Fast Fourier Transform (FFT). Spafford attributes CUDA’s better FFT performance on its use of a fast intrinsic, with OpenCL implementation (NVIDIA’s in this case*) employing a slower, more accurate version. If the implementations are matched, the performance difference goes away, says Spafford.

Others have found similar behavior on stand-alone science applications. A research group at Dartmouth running a numerical model of gravitation waves with OpenCL and CUDA found similar performance between OpenCL and CUDA, in this case on Tesla GPUs and IBM’s Cell BE processors. In the resulting paper, the researchers conclude that “an OpenCL-based implementation delivers comparable performance to that based on a native SDK on both types of accelerator hardware.”

GPU software maker AccelerEyes has seen CUDA and OpenCL performance equalize. The company, which recently released OpenCL-powered beta versions of their two flagship software products, ArrayFire and Jacket, has found that for most kernel codes, the two technologies now exhibit similar performance. Like ORNL, they found FFT speed is still better on CUDA due to NVIDIA’s faster implementation, but AMD’s OpenCL compiler and libraries have improved considerably, both in scope and performance.

According to AccelerEyes CEO John Melonakos, over half of their customers develop their GPU-accelerated code on their PCs before deploying to a workstation or cluster, so the ability to support non-NVIDIA hardware can be quite useful. For example, customers using MacBooks as development platforms couldn’t run CUDA there because Apple has no NVIDIA GPU option on its latest laptops. And since the AMD OpenCL libraries that AccelerEyes used in their beta offerings work just fine on Intel CPUs, AMD CPUs, and NVIDIA GPUs, there are no hardware incompatibility issues.

Then there are users who are just unwilling to adopt vendor-specific software stacks such as CUDA. “There are a class of people who absolutely want to do GPU computing but are resistant to anything that is vendor-locked,” Melonakos told HPCwire. He says this is group that has jumped onto their OpenCL-based offerings first.

To counter that kind of perception, NVIDIA has recently opened up the CUDA compiler source code for third-party developers. Significantly though, NVIDIA is not putting its all-important CUDA math libraries, like CUBLAS and CUFFT, into the open source pot. According to Melonakos, the large and mature library set is CUDA’s real strength in the technical computing arena. Open source or not, NVIDIA still retains control of the CUDA software technology, which is why it is still perceived as a vendor-specific solution.

Even NVIDIA and Intel are hedging their bets with OpenCL though, with both vendors offering software hooks for their respective hardware. At this point, these companies are providing this support as a nod to their mobile computing developers (although Intel is reportedly working on a MIC processor port too). But since there is an increasing amount of cross-pollination between mobile and HPC these days, it’s not clear how developers will end up using these technologies.

In fact, if the mobile space latches onto OpenCL in a big way and it becomes the standard low-level solution for heterogenous computing, that could help speed its adoption at the high-end. Once OpenCL reaches a critical mass of acceptance in a volume market such as that, there will be a rapid increase in demand for robust compilers and libraries. As Melonakos put it: “I dont think OpenCL is going away.”

[Editor’s note: The original article erroneously stated that the SHOC benchmark work used AMD’s implementation of OpenCL, rather than NVIDIA’s. We regret the error.]