Heterogeneous processing or co-processing on chips other than the CPU is the most recent trend in HPC. To some extent there has always been a small fringe element pursuing this direction, but as recently as a few years ago, a colleague claiming to be coding a GPU for physics or chemistry calculations would have been politely avoided. Programming FPGAs in strange hardware languages was even more far-fetched.

In the past few years, however, there has been a rich diversity of efforts and support from major HPC vendors. This year brings at least two conferences focused on heterogeneous computing: The Symposium on Application Accelerators in HPC (SAAHPC09, U. Illinois-Urbana, July 28-30) and the CECAM workshop “Algorithmic Re-Engineering for Modern Non-Conventional Processing Units” (Lugano, Sept. 30-Oct. 2). Several other meetings are dedicated to one type or another of specific co-processing approaches.

The most prominent examples of heterogeneous elements and efforts in HPC include the rapidly growing GPU computing community supported by NVIDIA and AMD/ATI and reconfigurable computing on field programmable gate arrays (FPGAs). C-based APIs, such as CUDA put out by NVIDIA, have opened up GPU computing to a much wider audience. Other examples include the IBM Cell chip and ASICs, such as those available from ClearSpeed, as well as soon to be released chips with built-in heterogeneous elements, such as Intel’s Larabee and AMD’s Fusion.

As more HPC practitioners are adopting these platforms today, many organizations are now taking a second look and evaluating them for their needs. Companies, university departments and government agencies want to know if heterogeneous processing is another fleeting trend or a real, sustainable technology transition driven by long-developing forces. The questions organizations are asking are: Will heterogeneous processing be an integral part of future HPC? Is it here to stay? To attempt an answer it’s useful to consider the recent past of HPC that has been characterized by a move to computing on large clusters of commodity chips.

Recent Trends in HPC

The share of the TOP500 machines using x86 programmable machines progressed from negligible in 1999 to roughly 90 percent in 2009, the balance comprised mainly of IBM Power. The numbers for cluster architectures versus MPP and others show the same development. The progression toward HPC computing on large clusters of commodity computing has had many positive impacts, providing great price/performance ratios and a large pool of qualified programmers by pushing affordable and scalable technology down to the department level. While clock speed increased reliably HPC practitioners were willing to turn a blind eye to the deficiencies of commodity solutions; happy to type make on their new platforms and see a doubling of performance every two years. The party ended in 2004, however, when clock speeds began to stall and the problems of HPC commodity computing became more salient, especially the memory wall (further reading here and here) and the divergence problem.

The story of power dissipation and the saturation of CPU clock speed is by now well known in HPC. With more silicon area available and the inability to jack up clock speed further, CPU vendors did what any clever vendor would do — provide more of their key product on die. At Intel it was called “the right hand turn” and it began to show effect in the market in 2004. Before 2004 data from the TOP500 list shows that FLOP performance improved at a healthy factor of 1.8 per year with 1.4 from improved clock and 1.3 from simply having a bigger machine. Plotting machine size against time shows a clear inflection point around 2004 after which machines have mainly improved performance and kept on trend by using more and more cores for processing. The multicore transition started with two cores, is currently at four and six cores, and will soon move to eight cores and higher.

Problems with Commodity HPC

The truth though is that many — in fact, most — HPC codes don’t scale well past 16 processors at least in their current form. In a world where performance can only be improved by use of more cores this is not great news. In short, commodity trends have led to great capacity solutions but not capability systems. Seymour Cray stated it succinctly as “If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens?” Clearly one of the seminal influences on HPC and supercomputing preferred oxen to chickens, but the HPC menu appears to favor poultry at the moment.

The recent percolation in the market of heterogeneous or co-processing solutions may be viewed as a response to this capacity/capability gap and the opportunity to use the new silicon area offered by Moore’s law for something other than CPU cores. Once programmers understand multi-level parallelism is required or they reach the scaling limits of their problem, adopting a novel platform to achieve more performance does not seem unreasonable.

The Landscape of Heterogeneous Processing

The landscape of Heterogeneous HPC can be viewed as a continuum when parallelism is plotted along the horizontal axis and core complexity along the vertical (see figure below). At the extremes, CPUs are moderately parallel (2 to 4 cores) but highly complex while FPGAs are massively parallel with hundreds of thousands of very simple processing elements. GPUs and others heterogeneous elements fall in between. It’s interesting to note that multicores are moving down and to the right in this chart with more, simpler cores; an evolutionary approach advocated by the Berkeley report on parallel computing, while FPGAs may be moving up and to the left by including more specialized hard-cores such as DSP blocks. There is no reason to believe a-priori that all applications will map optimally to a CPU architecture. Additionally, the relative complexity of writing codes for each platform needs to be considered.

Our experience has been that development times for CPU:GPU:FPGA are roughly 1:1.25:3 for the same algorithm. This assumes a full-up parallel CPU optimization using low-level parallelism (SSE) and high-level parallelism (MPI) on the CPU, a CUDA implementation on the GPU and HDL coding for the FPGA by skilled programmers. When does it make sense to implement heterogeneous solutions? Key considerations are how well your algorithm maps to the platform and the operational use case.

Choosing Your Co-Processor

CPUs are obviously the default platform of choice with great clock speed, the ability to handle branching well and relatively easy coding. If your algorithm has a lot of branching and can’t be cast in a streaming or SIMD type formulation, CPUs are your best choice. If your algorithm is a floating point SIMD type problem that can be divided up into many independent threads doing the same operations on different data, GPUs may be a good choice. GPU programming is slightly more complicated than the full-up CPU optimization. It sometimes requires recasting the problem and the cache, or shared memory must be manually managed to achieve performance. If your problem is mainly integer or fixed point, can be cast into a streaming form, has non-traditional data representations and is spatially parallel, that is, able to be written as many independent calculation pipes, FPGAs may be an excellent choice.

Another consideration is the operational mode of your application. Is it under constant development or does development proceed for a time with long operational periods that follow in which the code is essentially run 24/7 in production mode? The latter situation justifies the cost required to port code to a heterogeneous platform and invest in the required hardware since it will be balanced by higher performance and lower operational power consumption per flop.

The Need for Speed

There are a few ways that high performance is actually achieved and they are nicely and symmetrically summarized by both space and time considerations. (This is particularly satisfying for a physicist.) Performance is achieved temporally by 1) operating on data faster with a higher clock speed and 2) implementing temporal parallelism (deep pipelines) for concurrence in time; and spatially by 1) moving data faster and 2) implementing spatial parallelism for concurrence in space (multiple parallel threads). Heterogeneous platforms differ by their relative strengths and weaknesses in one or more of these areas.

Summary

Seen in the context of the decided move to on-chip parallelism and the limits of computing on large clusters of commodity chips, heterogeneous co-processing fills a market gap that is not soon to disappear. Developers today are confronted with multi-level parallelism that spans the domain, process, thread and even the bit level in their traditional CPU-based systems. Confronted with this complexity and the requirements for better performance, they are considering alternate uses of the silicon in non-traditional platforms — GPUs, FPGAs and ASICs — to achieve their requirements.

About the Author
Dr. Natoli is the president and founder of Stone Ridge Technology. He is a computational physicist with 20 years experience in the field of high performance computing. He worked as a technical director at High Performance Technologies (HPTi) and before that for 10 years as a senior physicist at ExxonMobil Corporation, at their Corporate Research Lab in Clinton, New Jersey, and in the Upstream Research Center in Houston, Texas. Dr. Natoli holds Bachelor’s and Master’s degrees from MIT, a PhD in Physics from the University of Illinois Urbana-Champaign, and a Masters in Technology Management from the University of Pennsylvania and the Wharton School. Stone Ridge Technology is a professional services firm focused on authoring, profiling, optimizing and porting high performance technical codes to multicore CPUs, GPUs, and FPGAs.

Dr. Natoli can be reached at [email protected].