At this week's International Supercomputing Conference in Hamburg, Germany, two of the biggest topics on the agenda are heterogeneous architectures and GPU/accelerator computing. Those emerging trends are joined at the hip, thanks mostly to the efforts of NVIDIA and their industry partners. Intel's ongoing plans for its Many Integrated Core (MIC) co-processor and AMD's introduction of its CPU-GPU "Fusion" processors are yet additional indications that the industry is moving to an architecture where CPUs married to accelerators will provide the next big seismic shift in high performance computing.

And just in time. The HPC community has known for awhile that conventional CPUs, at least in their x86 form, will not be a practical path to exascale computing. That's not just academic theory. HPC vendors and users have come to realize that commodity CPU-based computing, even with multicore parallelism, can only go so far, performance-wise.

But is the emerging HPC heterogeneous architecture with discrete GPUs or Intel MIC co-processors just another dead end as well? That's what we set to find out in a recent conversations with John Shalf, who heads up the Advanced Technologies Group at the National Energy Research Scientific Computing Center (NERSC) in Berkeley, California. Shalf has given a lot of thought to this new computing paradigm, and at ISC'11 he'll be moderating a panel entitled Heterogeneous Systems & Their Challenges to HPC Systems.

Like all HPC researchers, Shalf is well aware of the impact of general-purpose GPUs and other accelerators in the supercomputing realm. And while he believes heterogeneous architectures will be the future of HPC, he is skeptical of the current implementations. Shalf has two main objections to the today's model: 1) the awkwardness of the accelerator as an external processor and 2) what he sees as significant shortcomings in the available programming models.

Like many in the industry, Shalf thinks relegating the accelerator to an external PCI device negates a lot of the performance advantages inherent in vector-like processors. The problem is that the time taken to transfer data between main CPU memory and local memory on the accelerator card via a relatively slow PCI Express (PCIe) connection can nullify any performance advantages gained by offloading the CPU. In essence, this has cast the co-processor as an I/O device.

But it's not just a performance issue. The external accelerator setup also drives Shalf's larger criticism -- that of the programming model. Having separate memory spaces for the CPU and accelerator means the application has to account for moving data back and forth between processors. And in Shalf's estimation, performing this data shuffle across the PCIe bus is tedious, error-prone, and complicates algorithm design.

On that last point, because data management is so critical to accelerator performance, the associated code often must be intermingled with the algorithm itself. In fact from Shalf's perspective, the lack of a unified memory space is a much larger issue than the difficulties entailed in porting codes to CUDA, OpenCL, OpenMP, or any other kind of parallel programming framework. "My concern with accelerators hanging off of PCI Express is that they distract us from the core issue of expressing parallelism."

Then there are the programming models themselves. Although Shalf recognizes that NVIDIA's CUDA programming environment is the most established and the most performance-friendly software environment for GPU computing, it is by definition, proprietary. "Anybody who has any history in computing has very little stomach for single-vendor solutions," he says.

OpenCL, on the other hand, is a hardware-independent, but not as mature as CUDA, and is unproven for performance-critical applications. Compiler directives offer a higher level framework, but as we'll see in a moment, it has its own challenges.

Despite those reservations, there have been GPU computing success stories at Shalf's NERSC. In particular, scientists with quantum chromodynamics (QCD) and quantum chemistry applications have hand-coded the underlying algorithms in CUDA and are enjoying some nice application speedups. In these cases, the codes are reasonably compact and amenable to GPU porting, so the programming effort is within the reach of small teams of developers.

For larger more complex legacy codes, the compiler directives approach offers a higher level alternative for programming accelerators. In this case, special directives are inserted into C or Fortran source to instruct the compiler to generate low-level instructions for the accelerator. The nice feature here is that such directives are ignored by compilers that don't support them. So as long as the original source code around the directives can be left alone, the application can be transferred from target to target, with just a recompilation.

PGI and CAPS enterprise have commercial compiler products for GPUs based on their own directive schemes, and the OpenMP group is developing an open-standards version for accelerators. All have the advantage of allowing developers to build on top of existing high-level source code, while maintaining some semblance of hardware independence.

But according to Shalf, the performance results on GPUs for existing directives implementations have not been promising thus far. Some of this has to do with the fact the directives don't address on-chip data stores (non-cache coherent shared memory and registers), which need to be explicitly managed for optimal performance. That management is level up to the intelligence of compilers, and Shalf is skeptical that they can deliver this level of sophistication.

Furthermore, the directives only partially hide the data management problem, so the application programmer will still be saddled with this distraction. OpenMP-supported compilers for the Intel MIC platform may yield better results, but that work is in its preliminary stages.

As far as maintaining target independence, from what Shalf has seen, the application of these directives tends to mangle the application source. As a result, in many cases it won't be possible maintain separate code bases for CPU-only and various accelerator versions, negating one of the main advantages of this approach. Shalf says the current joke going around the community is that the total amount of text in the accelerator directives exceeds the amount of source code that you're applying those directives to. "The environment is just not ready for the average user to hop onboard," he says.

Fortunately, the accelerator chip vendors seem headed toward integrated CPU-accelerator processors, doing away with the PCIe bus performance limitations and the associated memory management. AMD is furthest along in this regard with its Fusion processors, although the first iterations announced this year are all aimed at client-side computing. NVIDIA's "Project Denver" aims to marry ARM CPUs with future GPU cores in the 2013-2014 timeframe and will address server and HPC platforms. Intel has not publicly stated its intentions to have its MIC co-processor sharing silicon with Xeons, but given NVIDIA's and AMD's plans, Intel is almost certainly considering a future heterogeneous x86 chip.

Heterogeneous processors are nothing new to HPC. For example, in classic vector-based supercomputers like the Cray 1, the processor was a heterogeneous mix of distinct scalar and vector units. The reason nobody talked about the vector component as an accelerator was because both units shared the same memory space. But unlike the custom design of the Cray 1 processor, the new breed of heterogeneous chips will be based on commodity architectures -- x86, ARM, and NVIDIA or AMD GPUs.

When fat cores (the CPU) and thin cores (the accelerator) are integrated, their roles could become reversed in some sense. According to Shalf, the accelerator cores should be devoted to the application, since they are much more efficient at pure computation, sequential or parallel. He thinks the fat cores should be used primarily for operation system functions; these are infrequent occurrences, but ones that require a lot of energy and time. "It completely breaks the old paradigm," says Shalf.

As these specialized units become integrated into the processor, the notion of accelerators could fade away entirely. Just as floating point units and memory management units were swallowed on-chip, the accelerator would just become another processor component. At that point, compilers would have a much easier time of making the accelerator invisible to the application developer. And for them, that's the Holy Grail.