Two revolutions are now underway that will change computing forever -- if programmers can figure out how best to take advantage of them. The first is an explosion in the number of cores on a single chip, and the second is such a radical transformation of the microprocessor landscape that the geekerati can’t even agree on what to call it.
Let’s talk cores first. You may have a spiffy new MacBook Pro with a quad-core Core i7 or a Mac Pro with two six-core Xeons. Sorry, but you ain’t got nothing, sport. Intel, the maker of those processors, is working on many integrated core (MIC, pronounced “Mike”) chips that’ll embarrass today’s Cores and Xeons. A prototype codenamed Knights Ferry -- with up to 32 cores and 128 threads -- is in production now. Next year, rechristened Knights Corner, the first MIC chip will be released as a product with more than 50 cores and presumably more than 200 threads.
Don’t expect MIC processors to appear in your Mac anytime soon, though. They’ll make their debut in high-performance computing (HPC) machines -- but history is replete with breakthroughs that migrated from HPC to plain-vanilla PCs. The second revolution, however, is already available in your desktop or laptop computer.
The processors of this second advance—Intel’s 2nd Generation Core (a.k.a. Sandy Bridge) and AMD’s Fusion -- not only have multiple compute cores, but they also share the same slice of silicon with graphics processing units (GPUs) and specialized cores for video processing and other tasks.
Sharing computing chores among different types of cores is called heterogeneous computing by such industry heavyweights as AMD, ARM (the designer of the core inside your iPhone or iPad’s processor), and Microsoft. An Intel software exec with whom I’ve spoken prefers the term specialization.
What Intel’s MICs and heterogeneous systems have in common is that they’re both extremely tough to program. To make matters more difficult is the rapid rise of what’s called general-purpose computing on GPUs (GPGPU), in which computing jobs that lend themselves well to the massively parallel structure of GPUs are offloaded from the CPU to the GPU -- think video- and image-processing, for example.
There’s an open standard called OpenCL to tackle GPGPU computing, but it’s still a work in progress. Also, sadly, the popular low-level languages C and C++ are chumps when it comes to data parallelism. Microsoft recently introduced a parallelism-handling extension to the latter called C++ AMP (accelerated massive parallelism), but it’s limited to GPUs, not CPUs, and only GPUs that support DirectX 11—which, wouldn’t you know it, is a Microsoft graphics protocol. The GPU cores in AMD’s Fusion chips, by the way, support DirectX 11, while Intel’s Sandy Bridge graphics cores don’t.
MICs bring their own set of problems. For example, how should two cores comparatively far apart on the same chip share data without cramping performance? One proposed solution borrowed from the old days of grid computing is to keep the data needed for each core’s work close to it in cache, and not let any other core touch it. In the brave new MIC world, it seems, optimizing for data-movement efficiency can be more important than optimizing for computing-operation efficiency -- a concept that turns standard practice on its head.
Flash backward, say, 10 years. You fed a CPU a job, it completed it, passed on the result, and started the next job. Simple. Flash forward 10 years from now, and heterogeneous systems with hundreds of cores—compute, graphics, video, encryption, whatever -- will be simultaneously churning scores of massively parallel workloads, optimizing data flow and positioning, and somehow all staying on the same page.
That is, if software engineers can figure out how to orchestrate all that complexity. I’m betting that they will.
--
Since the late 1980s, Rik Myslewski has paid his rent by keeping an eye on Apple. He was editor-in-chief of MacAddict from 2001 until its transformation into Mac|Life in early 2007, and is now a member of the snarkily sophisticated team at London’s The Register, which is “biting the hand that feeds IT” daily at www.theregister.co.uk.
Morfeo.Matrixx
August 16, 2011 at 8:27am
Rik misses the point with General Purpose GPU's (GPGPU), it's purpose is not to process standard GPU's workload like video and image processing that are well served by conventional GPU programming; they're intended for calculation-intensive applications such as scientific simulations, weather predictions, security encryption testing, etc.
I agree with DJSPIN80, these MICs are overkill for PC's (remember that we are in the verge of the "post-PC era"), they will be important for HPC and the new breed of video consoles.
DJSPIN80
August 01, 2011 at 7:24am
I wouldn't worry too much about this. While having multiple cores is nice, 90% of software is definitely not gonna need this.
OS X is the only OS I can think of that actually makes use of multiple cores and the GPU efficiently. Very few tasks require the use of a GPU computational unit, unless you're processing large amounts of SIMD (Singly Instruction, Multiple Data) stuff. SIMD is interesting, because almost all image, audio and video related processes are SIMD instructions (you typically will perform the same instruction on multiple datasets, like embossing an image).
I'm sure intel has a lot of those answers already figured out. One way they got around to working with multi-core CPU's is to use a shared cache (L3) and allow for a smaller, L2 cache to be processor specific. They can scale this model with 2, 4 or 50 cores. As long as each core is grabbing stuff from a shared L3, they can reduce duplicated work amongst cores.
rogology
July 27, 2011 at 2:57pm
One step closer to Singularity[?]
Is Steve Jobs a member of the Singularity Institute? I wonder what his thoughts are on it.
