Frameworks
The Parallel Problem
The transition to parallel processing won't be easy.
Every so often developers are confronted with a big-picture challenge that demands a fundamental change in the way they work. In the 1990s object-oriented programming posed such a challenge, and everyone from language designers to tool makers to rank-and-file programmers spent the better part of a decade mastering, manipulating and arguing over object-oriented concepts.
With the demise of Moore's Law -- at least, as it pertains to raw clock-speed increases in processors -- the developer community is ramping up for its next great challenge: the move to parallel programming.
Anders Hejlsberg, the Microsoft technical fellow responsible for guiding the C# programming language among other key projects, says the transition to parallel processing won't be easy. He says the early hope that developers could simply throw a "slash-parallel switch" in the compiler to produce concurrent code just isn't going to play out.
The problem is that systems today aren't designed to break up logical units of work for distribution across many CPUs. And to achieve dynamically scaled performance, that work must be finely granularized. Threading just won't do.
"Your program needs to be written differently, where there's not just decomposition, but even in a sense an over-decomposition of units of work that can be individually scheduled," Hejlsberg says.
There's a lot of work that needs to be done at the language, compiler and API level before that becomes possible. "We know for a fact from our experience with functional programming," says Hejlsberg. "If you could write programs that were provably pure, and all objects are immutable and there are no global variables; it is very, very hard to write programs that way and it is very hard to get those programs to perform."
Ultimately, Hejlsberg sees languages like C# adopting what he calls a "hybrid programming model" where mutable objects and variables can be isolated from purely functional sections of code. That way these objects can be changed and mutated, in private, without producing synchronization or shared space issues that derail concurrency.
Making things tougher is the scale of modern software and frameworks. There was a time when you could go back and rewrite an application designed to run in a 64K or 640K address space. "But it's no longer that way," Hejlsberg says. "It's a bottomless pit. The only way you really advance the state of the art here is by being very judicious about leveraging work that's already been done. It's increasingly important for us to find ways to just not obsolete everything."
What's your dev shop doing to prepare for parallel programming? E-mail me at
mdesmond@reddevnews.com
.
About the Author
Michael Desmond is an editor and writer for 1105 Media's Enterprise Computing Group.