
When applied to multicore programming, Sun Computer's take is apt.
"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.
This, of course, is exactly the same kind of efficiency that you get from parallel computing. But writing algorithms that can take advantage of parallel processors isn't easy in today's languages. There's nothing about the grammar of a for-next statement that lets the system know that it's OK to parallelize that loop. Instead, you have to manage the calculus of making it parallelizable by hand. Lose track of what's happening in the system and you can quickly end up in a "Sorcerer's Apprentice" scenario."
In Fortress, on the other hand, language constructs such as for-next loops are parallelizable by default. The Fortress specification supports the concept of transactions within the language itself, which means that complex calculations can be computed as atomic units, independent of any other program threads that might be running.
Ah, if Sun only knew how to do interfaces, they, and not Apple, would be the darlings of the tech world.

No comments:
Post a Comment