Since 1986 - Covering the Fastest Computers
in the World and the People Who Run Them
February 28, 2012
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.]
There are 2 discussion items posted.
One Correction\Clarification
Submitted by
kspafford
on Feb 29, 2012 @ 10:20 AM EST
The comparison in the slides is NVIDIA's CUDA and NVIDIA's OpenCL, not AMD's OpenCL implementation.
Also, the slides go on to show performance for FFT being equivalent when matching intrinsics (i.e. __sin() in CUDA and native_sin() in OpenCL) are used.
Post #1
Re: One Correction\Clarification
Submitted by
cgorac
on Feb 29, 2012 @ 1:24 PM EST
...which makes results completely as expected - why would anyone expect anything different as CUDA and OpenCL are rather similar, and one revision of CUDA SDK NVIDIA decided to use LLVM-based compiler for CUDA too (I think they used this one for OpenCL previously)?
As far as the article above itself concerned - every now and then alike articles pop up, claiming that OpenCL is running stronger and stronger vs. CUDA etc. In my experience, this is far from truth - I was working on lots of different GPGPU projects and within lots of different organizations throughout past couple years, and I never saw an incentive to go for OpenCL. Namely, you just can't write single OpenCL code to work optimally on all different types of platforms, you just have to tweak individually for each platform, so this whole talk of OpenCL making life easier for programmers is just plain untrue. Furthermore, and what is probably even more imporant, CUDA has *much* richer ecosystem of tools and libraries built around it. Thus, I see no reason why would anyone choose OpenCL over CUDA in case CUDA is available for his platform, and with recent developments (I mean primarily on PGI guys work on CUDA x86, as well as on NVIDIA open-sourcing their CUDA compiler), I'd expect CUDA to actually cover more and more platforms.
Post #2
|
Join the Discussion |
Apr 18, 2012 |
SoftLayer joins ranks of HPC cloud vendors.
Read more...
Apr 17, 2012 |
The chipmaker hints its manycore coprocessor could find a home in the enterprise.
Read more...
Apr 16, 2012 |
Recent advancement in big data, analytics, and language recognition could be setting the stage for a machine that could act like a human.
Read more...
Apr 12, 2012 |
As processor core counts rise, MIT research suggests on-chip networks will be needed.
Read more...
Apr 11, 2012 |
Iceland offers inexpensive, renewable energy for HPC colocation.
Read more...
04/02/2012 | AMD | Developers today are just beginning to explore the potential of heterogeneous computing, but the potential for this new paradigm is huge. This brief article reviews how the technology might impact a range of application development areas, including client experiences and cloud-based data management. As platforms like OpenCL continue to evolve, the benefits of heterogeneous computing will become even more accessible. Use this quick article to jump-start your own thinking on heterogeneous computing.
04/05/2012 | Appro | Designed to meet the growing global demand for HPC solutions, Appro's Xtreme-X™ Supercomputer delivers superior performance-per-watt and reduced I/O latency while bringing significant flexibility to HPC workload configurations including capacity, hybrid, data intensive and capability computing.
