ParallelFX: multi-processing extensions for .NET Framework

It is interesting how new solutions bring new problems: when Intel noticed that Moore's Law was loosing steam, it had to look for a new way of producing ever more powerful computers ¿their solution? Put more CPU's on every chip (the famous multi-core), they started shyly (2 with Core Duo) then they got up to speed (4, 8 CPU's) and now nobody's laughing when someone says that in 10 years home computers will have 32 or 64 CPU's.

But this solution brought a serious problem: most programming languages used nowadays not only ignore but are rigthdown inadequate to leverage these multi-core chips, to understand why, let's consider this really simplistic example:

x = f() + g();

One idea that comes quickly to our mind is to send the execution of f() to one CPU and the execution of g() to another and we'll catch up at the finish, but there are big issues here: what if f() and g() touch certain global variable (heck, any shared state, like a database connection), note that in such a case if f() goes faster than g() you may get a different result than if g() is faster than f(), in other words f() + g() is not deterministic anymore (whereas it used to be when we had just one CPU).

This is just a simple example of what can go wrong if we try to "just use" a multi-core chip with Java, VB or COBOL. Thus, whereas thanks to Moore's law we programmers got ever more computing power for free, with multi-core chips -powerful as they are- Moore's paradise is lost. Now we have to write (or re-write) specific code to leverage the power of parallelism.

But, lucky as we are, every problem seems to have a solution, and in this case we have a few options (in order of "radicality"):

1. Use languages intentionally crafted for multiprocessing, like Erlang, where processes, message passing and synchronization are part of the primitives of the language
2. Use languages whose same nature isolates one function call from another (i.e. where calling f() neither depends nor affects calling g()), languages where side-effects are not allowed or are strictly controlled. Like Haskell or F#. In fact, parallelism is one of the reasons functional languages are drawing so much attention these days.
3. Extend existing platforms with classes and APIs that allow higher level constructs (i.e. your favorite programming language) to leverage parallelism in an easy (albeit not transparent) way.

This latter option is the less radical but maybe this is exactly the reason why it will become the most prevalent (so that what's already written don't need to be re-written). And that's why Microsoft, a couple of years ago already, started to play with the idea of extending the CLR with classes and APIs for parallel processing, the fruits of these labors is the first CTP of the Parallel Extensions to the .NET Framework (aka ParallelFX). ParallelFX defines classes and methods in .NET that allows C# 3.0 (or VB 9) to express things like this:

Parallel.For(0, 100, delegate(int i) {
  a[ i ] = a[ i ] * a[ i ];
});

This parallel loop triggers many processes (up to 100 if there are the resources available) to execute a method (in this case, just to square a[ i ] ), synchronization, exception handling, etc. is done by ParallelFX. Intriguing, isn't it? To get a first idea of ParallelFX I suggest this article on MSDN Magazine and for those of you who want to dive deeper, there is the Parallel Computing Development Center. Beware, that much of the material is still experimental and change will happen, but as we say in Latin America "el que se mete más temprano a la cocina le toca una presa más grande" (no idea how you translate that).