Well, we're six months deep into 2010, and while there hasn't been a lot of blockbuster stories on the HPC front, the trends are unmistakable: more GPU computing, multicore multiplication in CPUs, and the search for a software model that ties everything together.

In fact, the biggest "story" of the year from a vendor had elements of all three of these trends. That was Intel's revelation of the upcoming "Many Integrated Cores" (MIC) HPC coprocessor, based on recycling the company's Larrabee technology. In a nutshell, the idea behind MIC is to build a manycore x86 chip with lots of vector horsepower for HPC-type codes. The original notion of using Larrabee as the basis for high-end graphics chips was jettisoned in December 2009.

The rationale behind MIC is to be able to preserve the industry's investment in x86 software in order to provide a smooth path to manycore technical computing. To help ease that transition, Intel will supply its own MIC compiler, parallel computing development tools and software libraries to support the new architecture.

Commercial offerings of this technology aren't scheduled to show up until late 2011, or more likely 2012, but early versions of MIC (just the Larrabee hardware, really) are already in the hands of selected customers. The first product will be built on the 22nm transistor geometries and is codenamed "Knights Corner."

Of course, Intel's manycore maneuverings are at least partially in response to the headway NVIDIA has made over the last four years on the GPGPU front. The newest Tesla products, in particular, based on the more general-purpose Fermi architecture, represent a direct assault to the dominance of the CPU in high performance computing. It's not NVIDIA's intent to make CPUs obsolete in HPC (at least not yet), but just to demote them to second-class citizens. The appearance of GPU-equipped Chinese supercomputers on the lastest TOP500 list may signal the beginning of the coming GPU onslaught.

GPU supremacy is not going to happen in the near term, though. Both Intel and AMD have been hatching new cores on their latest x86 silicon, and the OEMs are lapping them up. This spring, Intel launched its six-core Westmere EP and eight-core Nehalem EX Xeons, while AMD unveiled its 12-core Magny-Cours Opterons. More cores are on the way.

While there have been questions about the relative performance merits of GPUs versus CPUs for certain codes, a consensus does seem to be forming that the path from petascale to exascale computing will need the help of coprocessing accelerators -- if not GPUs, then something like them. Cray, IBM, Appro, Bull, SGI, and practically every other HPC OEM have added, or are in process of adding, a GPGPU option to their machines.

It's notable that the top eight slots on the June 2010 Green500 list of the most energy efficient supercomputers are all accelerator-based. Six of the eight are using the now-orphaned PowerXCell (enhanced Cell processor) technology, while the remaining two are equipped with GPUs.

Progress in making GPU programming easier, while not spectacular, has been relentless. CUDA 3.0 and OpenCL 1.1 were released in the first half of the year, and the ecosystem continues to grow around them, although to a much greater extent around CUDA. A sampling of new software support for GPU computing includes NVIDIA's Parallel Nsight plugin for Visual Studio, a PGI compiler upgrade for Fermi, new GPU routines from NAG, a Jacket upgrade from AccelerEyes, GPU debugger support from Allinea, a Linux-CUDA roll from Fixstars, CUDA Toolkit integration for Bright Computing's Cluster Manager, support for OpenCL in CAPS Enterprise's GPU compiler, and a new GPU compiler technology from PathScale.

CPU enthusiasts like to say that the cost of switching to a GPU computing model in many cases outweighs the performance increases you can extract from the hardware. While that may be true for some applications, for others, that is clearly not the case. One should also keep in mind that the most talked about alternatives to general-purpose GPUs are manycore CPUs and FPGAs. The programming models for the latter two are still immature and far from simple.

In any case, the search for simplicity is perhaps somewhat misguided when it comes to parallel computing. Hardware being what it is, programming is still more art than science. As PGI's Michael Wolfe once wrote:

One can claim anything is simple if it's simpler than something else that's even more complex. But I've said before that parallel programming is hard, and is going to remain so.