The Perl Journal January, 2004
Okay, I don't really need a supercomputer. I don't have any global weather modeling or thermonuclear explosion analysis that I need to do just now. But I want to need a supercomputer. There's just something about the thought of all that horsepower at my fingertips that's really appealing. And frankly, it looks like it would be fun to build a supercomputing cluster.
Certainly the folks at Virginia Tech made it look like fun. In fact, their success has led to a new formula for building supercomputers: Buy 1100 Apple G5s, promise some hungry grad students all the pizza they can eat, and set them to work installing I/O cards and rackmounting the computers. In three months, VT built a 10-teraflop cluster for $5.2 million, which is less than peanuts in the supercomputing world. (Check it out at http://computing.vt.edu/research_computing/terascale/.)
Clusters aren't new. The Beowulf cluster computing project is celebrating its 10th birthday this year. Beowulf proved the concept that commodity, off-the-shelf systems could form a reliable base on which to build the world's fastest computers. The plummeting cost of building such a cluster, however, is new. So is the ease with which they can be set up. You can buy clusters prebuilt from Dell; and Apple, keen to have more research dollars, is releasing its XGrid software to grease the supercomputing skids. (Apple is careful to point out, however, that XGrid all by itself won't replace true high-performance clustering software.)
Of course, most of us won't be building massive clusters in our basements. You still need lots of machines (and lots of expensive refrigeration) to really qualify as a competitive supercomputer. But home networks with more than five computers are becoming commonplace. It's not hard to imagine the day when grid computing services can be built in to mainstream operating systems, transparently allowing grid-aware apps on the desktop that use the untapped CPU cycles on your network.
But do we need that? Processors are already embarrassingly fast, and most apps don't really find themselves CPU-bound. Ten years ago, I used to wait several times a day for my computer to think about something. I can't remember the last time that happened. (With a mainstream desktop app, that is. Compiling with gcc is another story. And I still wait for disk-intensive operations all the time, of course.) But things change. Ten years ago, the horsepower to edit digital video didn't exist in most desktop machines. Ditto with professional-quality digital audio editing. Today, anyone can try their hand at these tasks. Who knows? Maybe the complex 3D animation done by professional special-effects firms will one day become the stuff of a mainstream, commercial app.
We're already seeing CPU-hungry tasks like digital audio moving onto the grid. Computer-based music is highly processor-bound: There's a clear upper limit to the number of simultaneous parts a computer musician can use, and software is emerging that can spread the processing load across a local network. WormHole, from apulSoft (http://www.apulsoft.ch.vu), is a good recent example of this. It routes audio across a LAN for real-time processing by other machines.
Only time will tell if we're really on the road toward ubiquitous grid computing. What we can say for certain is that where there are unused compute cycles, there are applications waiting in the wings to consume them.
Kevin Carlson
Executive Editor
The Perl Journal