Blade, Intel Push Parallel Programming, Software's Holy Grail

I was reminded of how far we've come in hardware, relative to our ability to exploit the immense processing power that's available, when a press release surfaced the other day from Intel and Blade Network Technologies. The two are teaming  to "change the way parallel programming is taught in U.S. High Schools." (I know, you're thinking that the first order of business should be the change the way regular programming is taught.)

It's a noble effort, for all the effect it'll have on kids who don't have enough real-world experience to know what they don't know. Plus, I'm in favor of anything which teaches newbies that there's a corpus of computer science knowledge and process to programming, as opposed to the bastardized approach that's developed, mostly on the consumer side, over the past quarter century.

Of course, it's easy to carp. Yet one must remember there's a reason that short cuts, workarounds, and the just plain inability to exploit the headroom of hyperthreaded hardware is commonplace. It's because parallel programming is touch stuff. The intellectual underpinnings for how to properly decompose apps haven't advanced all the much in a long time.

Those of us with long memories look back to the period from the mid-1980s through the early '90s as a golden age when it seemed like the challenge of parallelism would be met. That was the era where, on the hardware side, dozens of personal supercomputer makers flowered (and then were acquired, or sank).  To give those Thinking Machines and NCubes something to do, parallel programming languages like Sisal came into vogue. (Interestingly, Sisal, which had its code frozen in 1996, is actually still available, via SourceForge.)

Then we entered what I like to call the age (mostly, where we are now) where we pretended parallel programming was licked. Multiple physical and logic cores were available, and multiple threads on top of each core. But, in the vast majority of case, only the most gross level of decomposition and load balancing is/has been done.

I submit that running a different operating-system instance in a thread is not where we thought we were headed when we talked about achieving true parallelism, notwithstanding the advantages one can obtaining by doing this.

Also, when you look at the current situation, we've basically got many cases where there's the computer equivalent of V-12 engines being driven to the supermarket. There's so much processing power available, there's no imperative to use it efficiently.

I submit that this will change, as we get "greener." (Energy costs will become a gating factor, at least until we get smart and start building nuclear power plants. But I digress.)

Networking gear may in fact become an ongoing proving ground for better parallel programming techniques, because there's more of a history here of leaning and meaner hardware that's appropriately matched to the task.

So  let me close on the good news that mass(er) market parallel programming tools are coming into existence. Indeed, this was the impetus for the Blade and Intel announcement. Namely, they're going to do their student training using Intel Parallel Studio, which is brand new. (It was officially released at the end of May.)  Parallel Studio runs on top of Microsoft Visual Studio, and enables the creation of parallel apps in C and C++.

The takeaway here is it seems we're moving from the days when parallel compilers were arcane tools which could only be used by those who knew which switches to set.  Sure,  an environment like Parallel Studio may have to make compromises, and it can't do stuff in high level which can't yet be done in low level. But it's sure nice to see this stuff moving into the mainstream.

Follow me on Twitter.

Write to me directly [email protected].