Inside Parallel Extensions for .NET 2008 CTP Part 2

Posted By: Charles | Jun 5th @ 1:33 PM

Parallel Extensions simplifies development by providing library-based support for introducing concurrency into applications written with any .NET language, including C# and Visual Basic. It includes the Task Parallel Library (TPL), which provides imperative data and task parallelism; Parallel LINQ (PLINQ), which provides declarative data parallelism; and all new Coordination Data Structures (CDS), which provide support for work coordination and managing shared state.

In addition to CDS, this upgrade provides several improvements, including a new scheduler that is more robust, efficient, and scalable. TPL also exposes new functionality, including methods for continuations. PLINQ now runs on top of TPL, clarifies order-preservation, and provides several new operators.

The June CTP works with the .NET Framework 3.5 as a simple, small-footprint installation that drops a single DLL, documentation, samples, and registers the DLL with Visual Studio 2008.

Here, we continue the discussion with the key engineers of the Microsoft Parallel Computing Platform (which includes the Parallel Extensions for .NET...): Lead Developer Joe Duffy, Developer Huseyin Yildiz, Developer Igor Ostrovsky. Program Manager Stephen Toub and Program Manager Ed Essey.

We dig deeply into a lot of topics related to parallelism and conconcurency and how the new additions to the platform enable developers to exploit multi/many core processors in an elegant way.

Enjoy part 2. See part 1 here.

Tags: .NET, Parallel Computing Platform, Parallel Extensions, Programming

Rating:

Views (31,630)

Comments (15)

Downloads

Johannes
Johannes Hansen, Denmark

My 2 cents on the "ordered vs. unordered output default", issue...

At some point somebody mentioned that you might want to make the default ordered because that is what developers expect. I think that is wrong... Only developers who are used to sequential processing will expect the order of the output to be the same as the input.

In an asynchronous/parallel world the natural order of the output is unordered, so I really think you should stick with that as the default. Old school developers have to realize that they can't depend on the order unless they explicitly want to do the extra work of sorting the output.

So just to reiterate... The unordered output is the natural output in an parallel world. What do you think?

Kind regards,
Johannes

Johannes
Johannes Hansen, Denmark

In reply to Johannes

#Jun 5th @ 5:31 PM

My first post was supposed to say:

My 2 cents on the "ordered vs. unordered output default", issue...

At some point somebody mentioned that you might want to make the default ordered because that is what developers expect. I think that is wrong... Only developers who are used to sequential processing will expect the order of the output to be the same as the input.

In an asynchronous/parallel world the natural order of the output is unordered, so I really think you should stick with that as the default. Old school developers have to realize that they can't depend on the order unless they explicitly want to do the extra work of sorting the output.

So just to reiterate... The unordered output is the natural output in an parallel world. What do you think?

Kind regards,
Johannes

But now it's chinese or something... Whats up with the comment system? It seems like another post or something. Oh and when I edit it my original text show up just fine. It seems like the first comment on a video has some problems... Suresh's comment on part 1 of this video is also acting strangly... Charles?

aL_
mm.. linq.. *arrggha*

In reply to Johannes

#Jun 5th @ 5:41 PM

hm.. you post looks fine over here..
but Suresh's post is blank for me too :/

new c9 looks great though Smiley

i like the highlight of the post your're replying to if you mouse over the name of that poster Smiley

Charles
Welcome Change

In reply to Johannes

#Jun 5th @ 5:41 PM

There are some problems wth the comment system that the dev team is working to resolve. That said, keep on posting! Smiley

jjones

GREAT topic, GREAT interview!

Since I didn't know where to post this -
1.) New site is very slow on IE7 / XP SP3 : 55 seconds to display the first page.
2.) Unable to log in with IE7 - had to use FireFox which was faster to load and logs in fine.

stevo_
Casablanca != Manchester

Alright the comments are really screwed up.. but anyway, I really enjoyed that.. I thought the lazyinit class was pretty neat.. using a struct to get implicit initialization was an interesting 'party trick'.. Wink

I wonder if some of this stuff will become part of the base clr.. I'm interested because I understand most of this is pretty specific to wanting high power with parallelism.. but things like the LazyInit, are more like handy things that should just exist.. (a safe lazy init system)..

For example.. I might want to use the lazyinit 'everywhere' I use a lazy init pattern.. but don't feel is justifies having the entire parallel lib as part of the app/lib?

(pretty odd question I know)

Ed Essey

In reply to Johannes

#Jun 5th @ 5:41 PM

Thank you very much for this feedback on the ordering default.

Just to play devil's advocate, your opinion indicates that people will be thinking directly about the differences between sequential and parallel computing. Do you believe that it is in the overall best interest of developers to have to keep these concepts top of mind and need to consider them while programming? Do you think that it is required for developers to have separate sequential and parallel mindsets?

I bring this up not to argue, but to see what your thinking is around these points. The issues is pretty subtle, after all.

Ed Essey

In reply to stevo_

#Jun 6th @ 10:36 AM

It is too early to know at this point if Parallel Extensions to the .NET Framework will be in the base CLR or not. This is an option that we are actively considering. When we firm up on distribution plans, we will be sure to make it known; it is a big point after all.

Johannes
Johannes Hansen, Denmark

In reply to Ed Essey

#Jun 6th @ 12:33 PM

I believe that most developers, who has done any parallel programming, would agree that there is a (big) difference between sequential programming and parallel programming and I personally think that developers should recognice this difference. (I think of it kind of like the shift from procedural programming to object oriented programming) If they don't recognice the difference, I fear that developers might be misguided and in the end have a harder time understanding why certain problems occur.

Say for example when they do a parallel foreach with an ordered result as default and the performance sucks big time.... If instead the framework defaults to, what I believe is natural for parallel, an unordered result, then they will be forced to think about if they really need ordered results or not, and if they are ready to pay the performance penalty.

That said, I'm not against making the transition from sequential to parallel programming easier by obscuring the fact that you are developing parallel code, as long as it isn't also hiding serious issues which should be thought about.

In the end It depends on which goal you are trying to reach, ease of use vs. performance (in this case)... I think you should favor performance in a parallel framework.

PS: I just got home from a party and is still kinda drunk so please disregard any nonsense in this message Smiley