As CPUs and graphics processors (GPUs) evolve, many of their design features are beginning to look remarkably similar, and as a result, many of today's most common workloads will soon have a choice about where to execute. Users have been told by all the major hardware providers to expect processors that feature increasingly non-uniform and complex memory hierarchies, rapidly increasing core (and thread) counts and the integration of specialized acceleration units. These new processor designs will not be friendly to legacy code bases optimized for single-threaded, uniform memory systems, or, for that matter, to programmers without the time or expertise to create tuned, processor specific code. If we want to fully utilize these new hardware designs, then something needs to change about the way we write software.

Of course, some of these changes have been more widely evangelized than others. Many people know the history of multi-core on the CPU. When AMD shipped its first dual-core processor, multi-core processors really broke through into the commodity processor market. AMD was also first to incorporate both the memory interface logic and processor interconnect interface logic on the processor chip itself. And now Intel has shipped its first quad-core processors, as AMD is expected to do next year.

But what has happened to core count so far is merely the prologue to an imminent drastic increase in core counts. At the Intel Developer Forum 2006, for example, Intel showed off “Polaris”, a prototype processor with 80 cores, each with its own local, programmer-managed memory and with a fast on-chip interconnect. A wave of discussions ensued on numerous developer forums about whether the design was the best approach, but practically everyone agreed that there would be no easy way to program it.

In fact, industry pundits are predicting the solution to programming issues will be the next big software remediation effort as Moore's Law is realized by the doubling of the number of cores on a chip approximately every 18 months through 2015. According to Gartner Research vice president Carl Claunch, “If your software runs as a monolith, a single thread, you need to re-architect it to be parallel, otherwise the workload will not be capable of accessing the additional performance delivered with each new generation of systems.” Unfortunately, a majority of programmers are not sufficiently skilled to make applications multithreaded, yet the relentless doubling every 18 months will demand higher and higher levels of concurrency over time.

In another set of announcements, AMD has been talking up its “Torrenza” initiative. According to AMD, future CPUs won't be composed of homogeneous cores — there will simply be too many cores for useful work — but instead some of that chip area will be devoted to specialized accelerators. The first fruit of this approach will be the “Fusion” processor, an integrated CPU/GPU available sometime around the 2008 timeframe.

The GPU Design Evolution

Strangely enough, there are companies who already have lots of experience designing highly multi-core processors and enabling the software to take advantage of them: the GPU providers. GPUs have had massively multi-core designs for quite some time. The ATI R580 processor has 48 processing cores, while the just-shipped G80 from NVIDIA has an astonishing 128 processors. The GPU also has a history of adding accelerators for specialized functions, such as line-of-sight calculation.

Many people are familiar with the astonishing raw number-crunching potential of the GPU — the NVIDIA G80, for example, has half a teraflop of floating point capacity (for about $600) — but fewer are familiar with the other evolution in GPU designs. The GPU used to be a relatively inflexible, semi-fixed function processor, but the latest generation of GPUs, driven by Microsoft's DirectX 10 requirements, are outgrowing their graphics legacy and becoming, for want of a better term, “high throughput processors.”

With the new generation, (e.g., the NVIDIA G80), GPUs have added full dynamic flow control, integer support, full shared memory access, true scalar cores and multiple levels of non-uniform cache. Add to that the announcement by all GPU providers that double precision floating point is coming in the near future and you have a design that shares several striking features with Intel Polaris.

The Future of the Processor

Where are both CPU and GPU designs converging?

• Both processors will be massively multi-core –- think hundreds of cores — within a five-year period.
• Both processors will have complex memory hierarchies, with programmer managed core-local memories and core-local hardware-managed cache. (My own belief is that hardware-managed cache will decrease substantially in importance.)
• Memories will be strongly non-uniform with significant latency and throughput differences between local and non-local memory.
• Accelerators that can offer substantial speedups for specific tasks, either integrated on-chip or available via a HyperTransport-type interconnect, will be ubiquitous.

It's probably too much to say that GPUs and CPUs will merge. CPU features like a large cache as well as features such as branch prediction, speculative execution, etc. will likely never be adopted by the GPU. But GPUs, as they evolve into stream processors, should take over all those workloads that would rather have more floating point or integer ops, or faster access to a larger memory space. That means the majority of HPC applications, as well as any kind of signal processing or simulation application such as image processing, voice recognition, spam filtering, medical image analysis, etc.

Interestingly, another processor design that is converging on many of the same design features is the IBM Cell processor. The IBM Cell processor, used in the Sony PlayStation 3, embodies many of these features. The processor consists of a traditional PowerPC CPU core and eight additional on-chip “Synergistic Processing Engines” (SPE). Each SPE is, in-effect, a floating point co-processor core to offload computation from the main CPU core, and each SPE has its own local programmer-managed memory store of 256 KB. In addition, the local memory of each SPE can be accessed across a fast interconnect by other SPEs.

But What About the Software?

These future hardware designs couldn't be less welcome for the average software programmer. Until now, the programmer was insulated from changing hardware designs by their compilers and, occasionally, by libraries with standardized interfaces. At worst, programmers had to recompile their applications, or swap in a new library when they moved to a new generation of hardware. But no longer. To take full advantage of these new designs — whether on the GPU or the CPU — the programmer will have to extract and explicitly express parallelism (task or data parallelism) in their applications. And to achieve reasonable percentages of peak performance, they will also have to parameterize their applications to adjust for variations of cache sizes and cache hierarchies and add new code to handle NUMA effects. Given the effort and skill involved in doing this, I do not think this is likely to happen.

Instead, I think the most promising programming approach for overcoming the challenges associated with these future processors is what we call “stream programming.” Stream programming is a data parallel programming method compatible with distributed, explicitly managed memory that can offer superior productivity, performance and efficiency compared to alternative approaches. Stream programming requires the programmer to express the data parallelism in his or her problem. But all system specifics such as memory architectures, accelerators, etc. are abstracted from the programmer by a dynamic runtime which schedules and manages work appropriately based on the platform specifics. I believe that the stream programming approach creates the minimum possible change in the working habits of mainstream programmers, while extracting the maximum potential performance from these future processor designs.

As processor choices expand for many workloads, and as processor design features converge, the need for a viable software platform grows exponentially. New, and innovative technologies such as stream programming currently hold the most promise in fully exploiting the power and performance of these converging designs, propelling them out of the realm of research, and enabling the workhorse processors of tomorrow's high performance, and eventually general purpose computing.

—–

Matthew Papakipos is the founder and chief technology officer of PeakStream, a provider of a software application platform that uses the power of a new generation of industry-standard processors for high performance computing applications. Papakipos has been actively involved in the HPC market for more than a decade. As an early member of the Graphic Processing Unit processor architecture group at NVIDIA, he was responsible for personally developing several core architectural components of NVIDIA's revolutionary GeForce GPU. He is also the author of more than 20 U.S. patents on processor architecture and implementation. Matthew earned an SC.B. degree in Mathematics/Computer Science from Brown University.