The new Tianhe-1A Chinese system with a Linpack performance of 2.5 petaflops, placing it in the number one spot of the new TOP500 list to be presented at SC10 in New Orleans this month, has put "the cat amongst the pigeons" -- or should I say the "River in the Sky" -- as far as HPC politics in the USA are concerned. But away from the headlines there might be a more tempered reality.

I received a paper from the Department of Computer Science at the University of Warwick, a shorter version of which recently won Best Paper at the Daresbury GPU workshop. An extended version is to be presented at the PMBS workshop at SC10 on Monday, November 15. This paper, "Performance Analysis of a Hybrid MPI/CUDA Implementation of the NAS-LU Benchmark," (PDF) describes some interesting work being done at Warwick and with access to machines at Lawrence Livermore National Laboratory (LLNL). Essentially their study asks the question: As an organization, should I commit to a platform based on general-purpose GPUs (GPGPUs) or an IBM Blue Gene?

In procuring a new supercomputer, one takes many factors into consideration. Performance, availability and software; potential of the system for future scientific delivery; and viability of the company marketing it, are but a few. This is why the odds are often stacked in favor of established companies to deliver the next successful product. The Dahrendorf dictum that "history proceeds by changing the subject," however, provides the necessary optimism for aspiring new vendors of radical architectures. And there is a lot of fast-moving history happening in HPC.

As the reader knows there are lots of technical issues tied up in evaluating computer systems and making an informed decision: CPU speed, memory size and bandwidth, communication latency, scalability, capability, electrical power consumption, ease of supporting legacy code, etc. Indeed one needs to take on board the integral of all resources that contribute to the total cost of ownership (TCO). I think this study from the University of Warwick potentially captures the essence of the interesting crossroads at which current HPC finds itself, as ORNL, LLNL and others are now demonstrating.

Using benchmarking and performance modeling, the Warwick team was able to address some of the underlying technical issues, speculating as to the likely performance and power footprint of possible large-scale solutions based on GPGPU and Blue Gene platforms.

Before I offer a perspective of their findings let me clarify what the Warwick study focuses on. After discussing the potential problems facing the HPC industry in its aspiration to deliver exascale systems by 2015-18, they then compared the performance of pipelined wavefront computations (a class of parallel application), running across multiple GPU nodes against an InfiniBand-based cluster of AMD processors and an IBM Blue Gene/P. They augment these runtimes with projections from a recently-developed analytical model of NAS-LU, a computational fluid dynamics benchmark that employs the wavefront algorithm. This study says nothing about other mainstream supercomputers from IBM, Cray, HP, SGI, NEC, Fujitsu, and so on, or other classes of computations, but one can clearly see where their work is heading.

As the reader is aware an interesting race is emerging in supercomputing. In 2011/12 Lawrence Livermore National Laboratory will deploy their 20 petaflops Blue Gene/Q Sequoia system based on future IBM Blue Gene technology. At the same time, Nebulae and Tianhe-1A at the Chinese National Supercomputing Centers and, at a future date, Jaguar at the Oak Ridge Leadership Computing Facility (OLCF), are employing NVIDIA GPUs to attain multi-petaflops systems.

Of course large computing facilities such as LLNL and OLCF buy both, but for those organizations with more modest budgets, a choice must be made?

What makes these architectures different?

The Blue Gene, currently in its fourth technology iteration, owes its design to a previous debate in the late 1990s on how to achieve petaflops for a specific application, namely protein folding. At that time, general-purpose computers could not deliver the needed performance within reasonable power and footprint constraints. To overcome these constraints IBM aptly adopted a reduced instruction set design. To paraphrase Einstein: "A computer (theory) should be as simple as possible, but not simpler."

The Blue Gene approach to building large supercomputers is to take a large number of relatively-simple processing cores and to connect these via a low latency, highly-scalable interconnect. This has the advantage of creating a high aggregate memory bandwidth (as each core is connected directly to its own memory) whilst maintaining low power consumption because of the low clock frequency and simple design of the processor. The simple nature of the cores makes porting of existing MPI-based codes easier as few modifications are needed, assuming the code presents good scalability. In order to maintain efficient power usage and use of physical space, the Blue Gene/P has a maximum limit of 1GB of memory per execution core.

The Blue Gene architecture is highly rated. The project was awarded the National Medal of Technology and Innovation by U.S. President Barack Obama in late 2009. Its main architect, Alan Gara, is to be awarded the prestigious Seymour Cray medal by IEEE at this year's Supercomputing Conference in New Orleans.

In contrast, GPU-based machines are being produced from high-end designs based on consumer-grade video and graphics cards -- an example of history proceeding by changing the subject. Because of the significant economies, this has the potential to offer high performance at lower cost. The approach utilizes parallelism in the form of a large number of lightweight threads which provide good performance provided each thread executes the same instructions. If the control flow diverges, the penalties can be very costly. In a sense these are a modern equivalent of vector processors but with the ability to simultaneously execute considerably larger numbers of instructions. Currently, most GPU clusters are small scale and are connected by InfiniBand, which requires messages to be copied from the GPU to the main host memory and then from the memory to the remote node.

This "double-penalty" creates a high cost in exchanging data between cards, unlike the Blue Gene system where the low latency interconnect makes message passing relatively inexpensive. The high compute power per GPU concentrates the equivalent processing power into fewer numbers of nodes helping to reduce, but not eliminate, the scalability requirements of the application. However, where communication is needed it is expensive, creating significant problems for applications which need to scale to thousands of GPU devices. Current GPU designs have either 3 GB or 6 GB of memory which, when divided between the execution threads, yields a very small amount of memory per thread -- considerably less than conventional clusters based on general-purpose processors or a Blue Gene/P system.

The GPGPU-Blue Gene debate is not simply one of hardware. Application developers are also preparing for change. For many years HPC experts have warned that performance gains to applications from higher clock speeds and more memory per core, such as that seen in the blistering Intel Westmere, are not guaranteed in future architectures. The Blue Gene/P typically has 1 GB of memory per core, which for many application developers is like squeezing an elephant into a mini. An investment is needed to modify the application code to meet this memory constraint. GPU solutions require an even tighter squeeze (6 GB shared memory per 448-core device), not to mention the contortion needed to engineer core code kernels for the GPUs (whilst avoiding canceling out any benefits because of data transfers, etc).

Given that HPC code development and maintenance is the bread and butter of supercomputing programs, and occupies the largest proportion of the overall cost, it is not unreasonable to ask in which direction we should be steering application effort.

What can be learned from current Blue Gene and GPU-based systems?

There are significant installations of both Blue Gene and GPU-based systems. In the June TOP500 list, Lawrence Livermore's Dawn system, based on Blue Gene/P, clocked in at 415 teraflops and Nebulae, based on GPUs, clocked in at 1.271 petaflops. So what lessons if any can be drawn from these systems?
 
The study from the University of Warwick addresses this question: "Given what we can benchmark on current GPUs and Blue Genes, can we model how an application will behave on such systems at petascale?" The authors of this study, Pennycook, Hammond, Mudalige and Jarvis consider not only what this means in terms of raw performance, or time to solution, but also what this costs in terms of power budget.

Pennycook and his colleagues ask how many Blue Gene cores are needed to get equivalent performance to that achievable from a GPU-based solution. Their work uses extensive benchmarking of HPC-capable GPUs, including the NVIDIA C2050 built on the 'Fermi' architecture, alongside Nehalem-class CPUs and the Dawn Blue Gene/P system at LLNL. Performance models are built, for each class of system, which allow them to investigate the performance of applications at scale. Such performance modeling techniques are also used in benchmarking and procurement.

Their work provides some eye-catching results:

1. Taking the NAS-LU parallel benchmark code as an example, the equivalent Class E time-to-solution requires a Blue Gene/P to have 8,192 cores compared to 256 Tesla C2050 cores, 32 times more processing elements than a GPU-based system. This large difference may tempt you, but before running to your nearest GPU outlet to place an order, reflect on this: the processing elements of the Blue Gene solution require around 33 kW, whereas the smaller GPU system requires a maximum of 60 kW.

2. The theoretical peak of the GPU solution is nearly five times that of the Blue Gene. Is this another reason to visit the GPU store? If you are interested in your position in the TOP500 List, then yes, go GPU, but if you are interested in higher sustained performance as a percentage of peak then proceed with caution. The GPU solution clearly outguns the Blue Gene on peak, but achieves an equivalent time-to-solution in the NAS benchmark test.

3. Peak versus actual performance is hotly debated, and this study stokes the fire. The performance results of China's Nebulae system are revealing, and supportive of this argument. The machine has a theoretical peak of nearly 3 petaflops, but Linpack can currently only deliver 1.271 petaflops of that peak. In contrast the Dawn Blue Gene/P at LLNL has a theoretical peak of 0.5 petaflops and delivers a Linpack performance of 0.415 petaflops. This begs the question: what hope is there for applications, and should an organization be investing in peak or in achievable?

4. GPU single-node performance is second to none. Pennycook et al acknowledge that the single node performance of a GPU is a real win. The same NAS-LU example ran approximately 7 times quicker on the GPU than it did on state-of-the-art CPU-only solutions from Intel and AMD.

But Pennycook is quick to point out that "these headline figures often fail to consider interconnect overheads; we still need to connect these GPUs somehow."

An interesting observation in their results is that the Blue Gene scales well. So much so that at around 16,000 Blue Gene/P cores, the equivalent time to solution would only need four times fewer GPU processing elements. What this demonstrates is that the GPU-to-Blue Gene ratio is high for smaller systems, but it decreases as the systems get larger. This is significant in terms of power; 16,000 Blue Gene cores require around 66 kW, 4,000 Tesla C2050s require a maximum of 974 kW.

So where does this lead?

The authors of this study state: "The performance of these architectures raises interesting questions about the future direction of HPC architectures -- in one case we might expect smaller clusters of SIMT or GPU-based solutions which will favor kernels of highly vectorized code or, alternatively, we might expect highly parallel solutions typified by the Blue Gene/P, where 'many-core' will mean massively parallel quantities of independently operating cores."

The Pennycook study is application specific, "but at the end of the day this is what these supercomputers are designed to support," he says. Their work is also being extended to applications from Rolls-Royce, AWE and others.

Re-engineering applications for both types of platforms requires significant investment: Blue Genes are memory constrained, have low clock rates and clearly excel at scale, which our current algorithms in many cases do not. GPUs on the other hand require the careful porting of core kernels, which will undoubtedly result in performance gains, but nevertheless needs clustering through effective interconnects, else any gains will be lost.

So what is it going to be, GPU or Blue Gene? It all depends on the size of the system. On first inspection, the GPUs show promising power efficiency, but this is just half the story. Utilizing the available peak of a GPU is a difficult challenge. The Blue Gene, however, is closer to traditional designs, so realizing performance on these platforms presents fewer programming challenges, as long as the algorithms themselves scale.

In my view, this study by the University of Warwick is an invaluable contribution to the debate about emerging architectures and algorithms, in which the HPC industry needs to engage in its pursuit of exascale systems.
 
Enough for now. Just go along to the PMBS 10 workshop on Monday, November 15, in New Orleans and join the debate.

Note: The International Performance Modeling, Benchmarking and Simulation of High Performance Computing Systems workshop (PMBS 10) is part of the SC10 Technical Program. The workshop will take place on Monday, November 15, in rooms 278/279 of the Ernest N. Morial Convention Centre in New Orleans, La.

-----

Copyright ©: Christopher Lazou