The GPGPU faithful received another round of encouraging news this week. In a report  published this week, researchers documented that GPU-equipped supercomputers enabled application speedups between 1.4x and 6.1x across a range of well-known science codes. While those results aren’t the order of magnitude performance increases that were being bandied about in the early days of GPU computing, the researchers were encouraged that the technology is producing consistently good results with some of the most popular HPC science applications in the world.

The work was presented in March at the Accelerating Computational Science Symposium, an event devoted to understanding the use of hybrid supercomputers for scientific research. The ensuing report published by the Oak Ridge Leadership Computing Facility, detailed the performance GPU acceleration across the science application spectrum — biology, chemical physics, combustion, nuclear fission and fusion, material science, seismology, molecular dynamics, and climatology.

The 11 simulation codes tested –  S3D, Denovo, LAMMPS, WL-LSMS, CAM-SE, NAMD, Chroma, QMCPACK, SPECFEM-3D, GTC, and CP2K — are used by tens of thousands of researchers worldwide. NAMD alone has over 50 thousand users.

It should be noted that all of the principle participants at the symposium, including Oak Ridge National Laboratory (ORNL), the National Center for Supercomputing Applications (NCSA) and the Swiss National Supercomputing Center (CSCS), not to mention symposium sponsors Cray and NVIDIA, have a stake in proving the viability of GPU-accelerated supercomputing. The three supercomputing centers recently made substantial investments in GPU-based HPC, ORNL with its upcoming 20-plus-petaflop Titan system, NCSA with the 10-petaflop Blue Waters supercomputer, and CSCS with its currently installed 176-node Todi machine.

Titan, Blue Waters and Todi are all Cray supercomputers with varying amounts of AMD Opteron and NVIDIA Tesla horsepower, although none with greater than a 1:1 GPU-to-CPU ratio. That assumes a certain balance in the application between the sequential pieces of the code that would best be run on the CPU and the parallel components that would be candidates for the GPU. But applications can have very different needs in this regard, so that hardware ratio may not always be optimal. Vendors such as HP, Dell, Appro and others offer systems with much higher ratios of GPU to CPUs.

To level the playing field as much as possible, the performance runs for the science apps were made on CSCS’s Monte Rosa, a Cray XE6 machine equipped with two AMD “Interlagos” (Opteron 6200) CPUs per node, and TitanDev, a XK6 Titan-based testbed that consists of hybrid nodes, each of which contain one NVIDIA Fermi GPU and one Interlagos CPU . So in essence, the applications were tested on the same two systems, one of which replaced the second CPU with a GPU in each node. Here are the results:

According to this, the Fermi GPU-equipped XK6 was able to extract between 140 and 610 percent of the application performance compared to the CPU-only XE6. As CSCS director Thomas Schulthess observed at the symposium, that takes into account the fact the Interlagos Opteron is a new x86 processor, while Fermi is a two-year-old design. The implication is that the upcoming Kepler K20 GPU, which is supposed to be available later this year (and which will be deployed in Titan and Blue Waters), should widen the CPU-GPU performance gap even more.

“It’s going to be interesting to see in the next few years if there’s going to be a small avalanche, or is a big avalanche coming that’s really going to revolutionize computational science.” said Schulthess.

Even though the researchers provided an apples-to-apples comparison from a hardware perspective, the application software implementation for the two architectures is, by definition, rather different. Although the report did not delve too deeply into the software frameworks, most of these GPU codes incorporated CUDA or CUDA-based libraries. Only two of the applications, CAM-SE and S3D, used a higher level programming approach: PGI’s CUDA Fortran compiler for CAM-SE and OpenACC directives (compiler unknown) for the S3D implementation. Neither of these did particularly well, relative to the performance increases for the other applications, but there are not enough examples here to make any generalizations.

The other thing to keep in mind is that is no guarantee that the code implementations for either the CPU-only or hybrid versions are optimal at extracting the maximum performance from the silicon. A Fermi-class Tesla M2090 module delivers 665 gigaflops of peak performance, which is about 5 or 6 times that of a high-end Opteron 6200. The only code that appeared to fully exploit the performance advantage of the GPU was Chroma, the code for high energy and nuclear physics. Since applications vary significantly in their potential to utilize a highly threaded architecture like a GPU, this should come as no surprise.

Another aspect that needs to be taken into account is power usage. Although the performance comparison between the two processors is a useful one, if codes can scale equally well on a CPU as a GPU, performance per watt becomes a more valid criteria. Since these GPU accelerators consume about twice the power of a high-end x86 under full load, that means each hybrid node uses 50 percent more power than the corresponding CPU-only one when those systems are running at peak.

That suggests that the GPU-accelerated version of these codes should probably run at least 1.5 times as fast in this configuration to keep performance per watt in line. (Note that half of these codes are clustered around that break-even point.) To be fair, that’s not precisely true, since when the graphics engine is not being fully utilized it won’t be drawing anything near its maximum wattage; in general the GPU is much more efficient at throughput computing than its CPU brethren. But the fact remains that the power-performance behavior of the codes needs to be factored in when you’re considering the advantages of GPU acceleration.

Another missing piece of this comparison is how well these same applications would run on NVIDIA’s HPC competition, namely Intel’s Xeon Phi (aka MIC) coprocessor and its very different software ecosystem. Of course, there is no Xeon Phi yet, so that comparison can’t yet be made. But by this time next year, teraflop-capable MIC and Kepler chips should be in crunching away at applications on production machines. At that point, the case for accelerated science codes could be even more compelling.