Parallel processing calls for a Fortress mentality

When you're the inventor of one of the most successful and influential programming languages of the last decade, what do you do for an encore? Judging by demos at the recent JavaOne conference, if you're Sun Microsystems, you invent another programming language. But Fortress is more than just another syntax to remember. Instead, Sun Labs is taking lessons learned from Java and applying them to the thornier probl

When you're the inventor of one of the most successful and influential programming languages of the last decade, what do you do for an encore? Judging by demos at the recent JavaOne conference, if you're Sun Microsystems, you invent another programming language.

But Fortress is more than just another syntax to remember. Instead, Sun Labs is taking lessons learned from Java and applying them to the thornier problems of application development for HPC (high-performance computing). If it succeeds, Fortress could become the language of choice for the new computing era.

The problem with most existing languages is that they were designed for an earlier generation of machines. Processing resources were scarce. Desktop computers typically gave you only one CPU to worry about, and parallel supercomputers enjoyed the rarified air of academia, where coders were accustomed to jumping through mathematical hoops to get their applications running efficiently.

Flash forward to today, however, and the computing landscape looks considerably different. Low-cost, commodity processors, clustered together over high-speed networks, have made HPC accessible to nearly anyone. The lowliest desktop PC might be powered by a multicore CPU. There's a boundless world of processing power out there, waiting to be tapped. Unfortunately, the popular programming languages of today simply weren't designed for the parallel-processing model.

Take, for example, the humble for-next loop. It seems unambiguous enough. If I tell the computer to perform the same task a hundred times, the program loops through exactly 100 cycles and then proceeds to the next instruction.

In real life, however, a task that can be described as "doing the same thing 100 times" is often more nuanced than it seems. If my task is to fetch water from a well, for example, one person armed with one bucket could make the trip 100 times to complete the task. But if I had a hundred buckets, and a hundred strong backs to carry them, I could complete the mission in one one-hundredth of the time. Barring any other bottlenecks, there's nothing about a trip to fetch water from a well that depends on anyone else's trip to the well; you can complete all the trips at roughly the same time.