Start • Prop Job • Cog in the Machine • Hubba-Hubba • Spin Control • It's a Cog's Life • Propeller Heads Wanted • Sources and PDF

From: PACT 2006 Publicity
To: tom.cantrell@circuitcellar.com

Subject: PACT ’06: Abstract Submission Deadline EXTENDED by 48 Hours

PACT’2006 CALL FOR PAPERS http://www.cs.virginia.edu/~pact2006/

International Conference on Parallel Architectures and Compilation Techniques. Seattle, Washington,September 16–20, 2006

Due to an unforeseeable hardware failure, the site hosting the PACT 2006 submissions was down for most of the day on Monday, March 27…

You’ve all heard the old saying that those who forget the past are doomed to repeat it. Well, in the case of computer architecture, it can be said that those who remember the past are doomed to repeat it too.

As I pondered my pile of punch cards some 30 years ago, little did I realize that the computer I was (ab)using, a mighty IBM 360/91, was a veritable architectural roadmap of things to come. Pipelining and cache—natch. Virtual memory—check. Superscalar—got it. Branch prediction and speculative execution—ditto.

Don’t get me wrong. The fact that the old-timey room full of big iron has been shrunk to a tiny chip is a wondrous thing. Not to mention the fact that today’s bargain-basement PC has more MIPS, megahertz, and megabytes than anyone dreamt possible back in the mainframe days.

Having incorporated all the historic architectural features, the silicon CPU performance improvements in recent years have mainly been driven by implementation (e.g., faster clock and more cache). Indeed, there are arguments that bloated designs (e.g., Itanium) have overshot the sweet spot on the architectural price/performance curve. The evermore expensive and power-consuming architectural tweaks seem to return little in terms of real-world (i.e., existing application program) speedup.

As with the big-iron mainframes of yore, today’s big-silicon mainframes-on-chip are running out of gas. What to do?

Where better to find the answer than at the first annual Multicore Expo? The premise is simple enough: Why not just use a bunch of simple and efficient processors rather than rely on ever-bloatier brainiacs?

The problem is that that’s a simple premise that’s been around a long, long time. I suspect there are few computer architects who, when pondering the single-CPU folly ahead, haven’t hoped for a multicore miracle. Yogi Berra might say, “It’s so simple that nobody’s done it.”

It’s time for a change. On the computing front (e.g., PCs and video games), you’re already seeing architects (Intel, AMD, Sony, IBM, and Sun) stick their toes in with multithread and multicore chips. The challenge here is getting the multicore chips to work well with traditional software applications and tools. 

On the embedded front, there are more futuristic approaches that combine tens, hundreds, and perhaps even thousands of processors on a single chip. Here we find a lot of novel tool concepts as designers try to reconcile evolutionary migration with revolutionary aspirations.

There’s a reason everyone stuck with the old single-core well past its prime. As baroque as the latest single-core CPU architectures are, multicore ups the complexity ante considerably. Traditionally, all you had to worry about was choosing from different architectures. Well, now you still have all the different architectures, but you also get to fret over numerous ways (e.g., bus, network, and pipeline) to connect them. Then there are the various intercore communication protocols to choose from (e.g., shared memory, message passing, and distributed objects). Finally, throw in all the new tools and languages that attempt to lay bare the pesky parallelism that’s so hard to find.

Try to juggle all the options and you’ll soon discover this multicore stuff can be pretty complicated. As I chatted with one of the Expo exhibitors at the reception, I joked, “beer and multicore don’t go together,” to which my burnt-out booth buddy replied, “Oh, beer helps—a lot.” Look at the bright side: if it were easy, none of us would have jobs right?

Like most computer stuff, multicore isn’t really a new idea. Just as that old 360/91 foreshadowed the brainiac microprocessors to come, the roots of multicore can be found in the boutique parallel-processing architectures (one example is described in James W. Moore’s “The HEP Parallel Processor”) that came to fruition during the Cold War (and many of which went down along with the Berlin Wall). These niche machines’ big-iron footprints and price tags appear quaint in retrospect, but that shouldn’t hide the fact that their designers had the courage to challenge the status quo of conventional computer design.

The difference between now and then? Moore’s law means that multicore no longer requires a roomful of hardware and a number of significant digits have been slashed from the price tag. That’s good news because another difference is that the single-core brainiac approach has run out of gas. Multicore is no longer an option; it’s the only way out.