Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Inside Parallel Extensions for .NET 2008 CTP Part 2

Download

Right click “Save as…”

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:

Follow the Discussion

  • Johannes Edstoft HansenJohannes 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 Edstoft HansenJohannes Johannes Hansen, Denmark
    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?
  • Allan LindqvistaL_ Kinect ftw
    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
  • CharlesCharles Welcome Change
    There are some problems wth the comment system that the dev team is working to resolve. That said, keep on posting! Smiley

    C
  • 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_stevo_ Human after all
    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)
  • 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.
  • 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 Edstoft HansenJohannes Johannes Hansen, Denmark
    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
  • This is great I played around a bit.

    Something of note that I think has to do with CLR rather than the extensions: It would seem that once multiple threads are used within the test console app it takes 10-50x (guess) longer to exit just normally. Even then it's just a second or so but it makes it appear that there is some problem there when things freeze for a second.


    edit: Went to verify this. It seems that the above delay only happens on the first (cold) run. Doesn't make it any less weird, what could there be happening upon exiting the app on first run as opposed to further runs? It's also possible this only affects debugging from VS.



    Another unrelated weird thing I noticed:

    System.Threading.Parallel.ForEach(items, (item,x) =>
    {
      Console.WriteLine(item);
      x // <<<< weirdness
    });

    If I type "." after the "x" it thinks x is an int and doesn't give any completion options. However if I put .Stop(); there manually, then build and then try starting another line with x, the IntelliSense completion window now says x is ParallelState rather than int. It still doesn't give completion options. However one time (seemingly random) it did give completion options with Stop among them.

    This is on RTM VS 2008.

  • I supprot Johannes in that unordered results should be the default.

    TPL and PLINQ should abstract away implementation details of parallel programming (as they do), but shouln't abstract the notion of parallel computing, which in its nature is unordered.

    Nobody complains about SQL not preserving results ordering by default. SQL is set based in terms of data, and parallel computing is in a way set based in terms of Tasks. We shouldn't fool developers into thinking that parallel programming is the same as sequential programming, because ideas behind them are quite different and developers need to be be aware of that fact.
  • Christian Liensbergerlittleguru <3 Seattle

    My take on it would be to return the output ordered. I know that the result is slower but that's something that the average dev would expect... they put something in, want the cores to handle it and get the result as it was entered before.

    Although if taking the SQL approach you would probably return it unordered... you need there to specify the ordering to get it ordered.

    But the question is: would the average dev expect that an array is returned in another order...

  • stevo_stevo_ Human after all
    I guess the thing is related to how much about parallelism you want to abstract away from the developer.. whats the core principals of the tpl?

    Personally I don't think you should return ordered by default, it suggests to me that the default of what a parallel action does is; return an ordered result set.. where as having to explicitely state unordered seems like im then asking the parallelism to do something more.. where as the actual actions of the tpl are the inverse.. the results DO come out unordered, and would need to be purposely ordered.
  • William Staceystaceyw Before C# there was darkness...
    Having "tried" implementing my own WaitAny and TPL (like) api before, I remember WaitAny was a tricky bugger and not sure I actually finished it to my liking.  Could someone write a little bit on how WaitAny was implemented and what the challenges where  to get correct behavior?  tia
  • William Staceystaceyw Before C# there was darkness...

    Because TPL is naturally a threading library, I would think the default of no order is correct as that is the whole point to run parallel tasks and today with our own manual threading tasks, we know (hopefully) order is not ordered.  I like Joe's ideas of mixing the order in debug mode to help prevent false expectations on order.

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.