As many industry watchers have noted, including me, the next few months will see the introduction of a raft of new x86 server chips that offer between 6 and 12 cores. Although both Intel and AMD have already fielded 6-core processors ("Dunnington" for Intel and "Istanbul" for AMD), the new Xeon and Opterons will set some new expectations in the x86 server chip arena.

For one thing, the "multi" in multicore is about to become a lot more meaningful. Instead of simply doubling the core count, which was the model in the past, when the industry moved en masse from uni-core to dual-core to quad-core, we're now going to see processors with 2, 4, 6, 8, and 12 cores filling different niches in the server space.

This month, Intel is expected to roll out its 6-core Westmere EP processor aimed at dual-socket platforms. For 4-socket systems and above, the 8-core Nehalem EX is expected before mid-year. Intel is also planning on a faster clocked 6-core Nehalem EX variant, which is targeted especially for the HPC market. Meanwhile, AMD is set to launch its 8- and 12-core Magny Cours Opterons at about the same time as the first Westmere chips launch. Magny-Cours, though, will support both 2- and 4-socket servers.

Given that diversity, server makers will have a lot more choice on how they want to balance FLOPs with memory capacity, memory bandwidth, and I/O in different product niches. This is especially true for HPC, where the memory wall problem is particularly prominent. In fact, in this post-quad-core era it's worth remembering the 2009 Sandia study that suggested performance would drop for certain data-intensive apps when the underlying platform moved beyond eight cores:

A Sandia team simulated key algorithms for deriving knowledge from large data sets. The simulations show a significant increase in speed going from two to four multicores, but an insignificant increase from four to eight multicores. Exceeding eight multicores causes a decrease in speed. Sixteen multicores perform barely as well as two, and after that, a steep decline is registered as more cores are added.

That suggests that the most likely consequence of core proliferation will be greater emphasis on memory capacity and bandwidth per node. As processors have added performance, the memory bytes per flop and bytes/sec per flop ratios have been dropping, leaving a lot of unused performance on the chip. To counter that, we're starting to see a trend back to big-node, shared memory systems. Frankly, most of the commercial solutions for x86-based systems are more focused on increasing memory capacity, rather than bandwidth, given that the latter is far more difficult to accomplish without design help at the CPU level. Nevertheless, increasing memory can indirectly help the bandwidth issue, since aggregate access increases as you add more RAM.

The move to bigger memory machines has already begun. NCSA is getting reading to install Ember, a large-scale shared memory SGI UV Altix super. That machine is going to be used for computational chemistry as well as solid and fluid dynamics research. ScaleMP, which uses its vSMP technology to concoct virtual SMPs, has had a number of wins lately, include the Gordon cluster at the San Diego Supercomputing Center. Although that machine is best known for its use of flash memory, the vSMP technology is used to build "supernodes" that can access as much as 2 TB of RAM. Relative newcomer 3Leaf Systems recently announced Florida State University will deploy the company's "fabric computing" technology to aggregate multiple Opteron-based nodes into virtual shared memory servers. Finally, although not aimed at HPC, IBM just unveiled its eX5 servers, which allows users to expand RAM to 1.5 TB per two-socket machine.

The burgeoning core count also raises a sort of existential question for a lot of HPC users. In a Linux Magazine article, Douglas Eadline noted that since more than half of HPC apps use 32 cores or fewer (according to both IDC research and a Cluster Monkey survey), it's possible low-end HPC work will migrate from clusters to single nodes. In that case, multi-socketed workstations could end up replacing traditional clusters.

Well, the sweet spot of such workstations is still dual-socket systems (as it is for servers), so we'll really have to wait until 16-core chips hit the streets next year to answer that question. On the other hand, considering that the latest GPUs from AMD and NVIDIA (especially the upcoming Fermi processors) can take the place of multiple high-end CPUs for a range of HPC workloads, we may not need dozens of x86 cores to push a lot of low-end supercomputing onto the desktop. In fact, the presence of general-purpose GPUs makes the use of double-digit core counts somewhat superfluous in these cases, unless someone can figure out a way match up graphics processors with CPU cores.

One final thought. When considering how multicore CPUs are distorting system balance, it's tempting to get hung up on efficiency metrics and maximizing hardware resources. But as John Gustafson has reminded us: "System balance is not about bytes per flops/s, mass storage/RAM, or any such ratios. It never has been. System balance means adding something to the design such that the percent improvement in value (performance, reliability, or whatever) is greater than the percent improvement in the total cost of ownership. A system is perfectly balanced when no further such improvements are possible."