I think there's far too much stuff going on with respect to parallelization on the .Net scene. Just off the top of my head, I can think of Task Parallel Library, Axum, all those weird Spec#-esque languages (okay, they aren't exactly being released, but still), the Concurrency Coordination Runtime (which, let's face it, is similar to what Spec#/Polyphonic C#/Cω are doing, which is join calculus), and then there's things like join macros in Nemerle (I beleive they are called 'chords' by many people now). And let's not forget F# async workflows. But wait, we also have Intel releasing a huge unmanaged (plain C++) stack on us as well. And Microsoft! So the number of three-letter acronyms (PPL, TBB, MKL and IPP) is sharply on the rise, but are we actually better coders because of it? Do we really have time to learn it all?

I don't. I wish I did. Lots of stuff is a lot of fun, but some of the stuff is just a rehash of the same idea over and over. For example, we've always had task-level parallelism, we were just either too lazy to do it properly, or we were feeling helpless and waiting for some miracle framework that will give us a 'fair' ThreadPool (called TaskManager, as it happens) that will distribute work properly because, apparently, ThreadPool doesn't get it quite right. And async workflows? Come on, we have the AsyncEnumerator that does it in C#. Exploiting the F# workflow semantics is very cute but, given the abrupt change in the coding style that's required, I'm not sure it's worth the bother. I can download web pages asynchronously in C# too, thank you very much.

Then there's data-level parallelism, that ubiquitous Parallel.For that we now have (or are about to have) as a way of blind separation of data into chunks. But, seriously, as soon as this tech started getting previewed, lots of people wrote the same implementation for .Net 2.0. So we could have had that too, ages ago.

And let's not talk of instruction-level parallelism because, really, .Net could easily support it (hey, Mono does), but for some reason all that SIMD goodness is lost on the .Net code. Which is a pity because sometimes it is a real benefit, and I for one am tired of using those weird __m128 types and lots of pointer arithmetic and such.

And don't get me started on Axum and the join semantics.

Just before I go off and stop ranting, I have to take a shot at PPL (Parallel Pattern Library), too. Seriously, we already have OpenMP support (which is fantastic, and 3.0 ought to be even more brill), and TBB has been out - what - a year, maybe? Maybe less, but introducing PPL into VS2010 seems like a last-ditch attempt to get people to not spend money on the Intel compiler and parallelization stack.

To sum things up (because this is starting to sound like a rand instead of a normal blog post), I personally am sticking with OpenMP, SSE/2 and the Intel stack for all the parallelization stack. P/invoke only looks scary, but you only need to learn it once. As for .Net 4.0 and all that Task/Future business - well, we shall see what comes of it. But, beleive me, the people who want to get good parallelization and multicore scalability are getting it already. And to those who are still doing their matrix math in C# on a single thread - well, I leave you to your own devices.