If there was a dominating theme at the Supercomputing Conference this year, it had to be GPU computing. From the influx of GPU-accelerated systems on the TOP500, including the number one system in the world to the inclusion of GPGPUs into nearly every discussion of exascale machines to the visibility of GPUs across the exhibition hall, the technology seemed to be ubiquitous at SC10.

Arguably, the biggest vendor announcement at the show was the launch of SGI’s Prism XL machine, and although that system is designed as a general-purpose platform for various kinds of HPC accelerators, it’s almost a given that the vast majority will be shipped with GPUs.

Today, every major and minor HPC system vendor now offers GPU-equipped servers, with plans by many to expand their portfolio over the next year. And that can only mean the customer demand for such technology is now palpable. In fact, if you aspire to be an HPC OEM or software provider and don’t have a GPU strategy, the next few years are going to be mighty lonely.

But not everyone at SC10 was hopping on the GPU bandwagon. (And I’m not just talking about the Convey folks.) There is a definite divide in the HPC application community about the value of graphics processors for science codes. I spoke with a number of developers who had played with GPUs and found they couldn’t realize that magical 10X performance bump they felt they needed to commit their applications to a new platform. Although there are plenty of technical computing applications that have been ported to CUDA, many — the majority, in fact — have not.

CAPS enterprise, makers of GPU-friendly compiler tools, offers a support service for porting codes to GPUs and found that 10X speedups should be considered quite good for an HPC application. According the them, getting to 100X or beyond would be attainable only by those algorithms that are not memory-bound, that is, those dominated by computation rather than memory access. Most of the customer applications they’ve worked with have been able to achieve between 2X and 10X performance increases when ported to GPUs, and sometimes that’s not enough for to justify a platform change. In some cases, reworking of the CPU component, alone, achieved a significant speedup. Only about half of the CAPS customers that were considering ports have made the jump to GPGPUs.

In talking with people here at SC10 and at NVIDIA’s GPU Technology Conference in September, my impression is that the bigger, older codes are more resistance to being ported to GPUs than smaller and newer ones. And it makes perfect sense. In many cases, those older codes are no longer attached to their original developers, which makes transforming the algorithms into a GPU-friendly design (or any design) that much harder. Also, legacy codes tend to have accumulated kludges and tweaks that make such redesigns extremely painful. This feeds into the human aspect of software engineering, where the if-it-aint-broke-don’t-fix-it crowd often dominates the software maintenance mentality.

This might help to explain the slow response of the US and Europe to adopt GPU-equipped supercomputers, at least at the level of the large national labs and universities. After all, this is where many of those legacy HPC codes are developed and maintained. That said, I suspect there are actually more GPU-accelerated clusters in the US and Europe than anywhere else; it’s the petascale systems that have not been forthcoming. At this point, the West is at least a year behind China and Japan in the GPGPU supercomputer arms race.

GPU computing skeptics can also point to evidence that there are better architectures for supercomputing already out there, or soon to be launched. For example, despite the enviable performance per watt of the graphics processor, the number one system on the just-announced Green500 list is a Blue Gene/Q prototype system. Of course, that’s cheating a bit, given that production Blue Gene/Q systems don’t yet exist. But the prototype Q did manage to beat the state-of-the-art TSUBAME 2.0 GPU supercomputer rather handily — 1684 megaflops/watt to 984 megaflops/watt. I suspect the “green” matchup will be much closer in 2011, when NVIDIA’s next-generation “Kepler” hardware and Blue Gene/Q are both in the field.

Also, the top system on the new Graph 500 list was the IBM Blue Gene/P system at Argonne National Lab. The Graph 500 attempts to measure the suitability of platforms for data analytics-type workloads, which is not the strong suit of the graphics processor, at least in its current incarnation. Graph problems require an architecture that can do a lot of random data accesses across memory at a very high rate. Few conventional computing architectures — CPU, GPU or otherwise — are any good at this.

Committed GPU computing dissenters are likely pinning their hopes on Intel’s Many Integrated Core (MIC) architecture, which is designed to address the same problem space as GPGPUs, but does so with a conventional x86 architecture. For the risk-averse, there is certainly an allure to recompiling your legacy source code with a future Intel compiler that will automagically spit out MIC code. But waiting until 2012 to see if that chip and compiler deliver as advertised could be the riskiest bet of all. Of course, we’ll have to wait until SC12 to see how this story turns out.