Visit additional Tabor Communication Publications
June 18, 2011
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.
May 23, 2013 |
he study of climate change is one of those scientific problems where it is almost essential to model the entire Earth to attain accurate results and make worthwhile predictions. In an attempt to make climate science more accessible to smaller research facilities, NASA introduced what they call ‘Climate in a Box,’ a system they note acts as a desktop supercomputer.
May 22, 2013 |
At some point in the not-too-distant future, building powerful, miniature computing systems will be considered a hobby for high schoolers, just as robotics or even Lego-building are today. That could be made possible through recent advancements made with the Raspberry Pi computers.
May 16, 2013 |
When it comes to cloud, long distances mean unacceptably high latencies. Researchers from the University of Bonn in Germany examined those latency issues of doing CFD modeling in the cloud by utilizing a common CFD and its utilization in HPC instance types including both CPU and GPU cores of Amazon EC2.
May 15, 2013 |
Supercomputers at the Department of Energy’s National Energy Research Scientific Computing Center (NERSC) have worked on important computational problems such as collapse of the atomic state, the optimization of chemical catalysts, and now modeling popping bubbles.
May 10, 2013 |
Program provides cash awards up to $10,000 for the best open-source end-user applications deployed on 100G network.
05/10/2013 | Cleversafe, Cray, DDN, NetApp, & Panasas | From Wall Street to Hollywood, drug discovery to homeland security, companies and organizations of all sizes and stripes are coming face to face with the challenges – and opportunities – afforded by Big Data. Before anyone can utilize these extraordinary data repositories, however, they must first harness and manage their data stores, and do so utilizing technologies that underscore affordability, security, and scalability.
04/15/2013 | Bull | “50% of HPC users say their largest jobs scale to 120 cores or less.” How about yours? Are your codes ready to take advantage of today’s and tomorrow’s ultra-parallel HPC systems? Download this White Paper by Analysts Intersect360 Research to see what Bull and Intel’s Center for Excellence in Parallel Programming can do for your codes.
In this demonstration of SGI DMF ZeroWatt disk solution, Dr. Eng Lim Goh, SGI CTO, discusses a function of SGI DMF software to reduce costs and power consumption in an exascale (Big Data) storage datacenter.
The Cray CS300-AC cluster supercomputer offers energy efficient, air-cooled design based on modular, industry-standard platforms featuring the latest processor and network technologies and a wide range of datacenter cooling requirements.