Inside Parallel Extensions for .NET 2008 CTP Part 2
- Posted: Jun 05, 2008 at 1:33 PM
- 37,069 Views
- 15 Comments
Download
How do I download the videos?
- To download, right click the file type you would like and pick “Save target as…” or “Save link as…”
Why should I download videos from Channel9?
- It's an easy way to save the videos you like locally.
- You can save the videos in order to watch them offline.
- If all you want is to hear the audio, you can download the MP3!
Which version should I choose?
- If you want to view the video on your PC, Xbox or Media Center, download the High Quality WMV file (this is the highest quality version we have available).
- If you'd like a lower bitrate version, to reduce the download time or cost, then choose the Medium Quality WMV file.
- If you have a Zune, WP7, iPhone, iPad, or iPod device, choose the low or medium MP4 file.
- If you just want to hear the audio of the video, choose the MP3 file.
Right click “Save as…”
- High Quality WMV (PC, Xbox, MCE)
- MP3 (Audio only)
- MP4 (iPod, Zune HD)
- Mid Quality WMV (Lo-band, Mobile)
- WMV (WMV Video)
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.
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.
Follow the Discussion
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
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?
but Suresh's post is blank for me too :/
new c9 looks great though
C
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.
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)
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.
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
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.
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.
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...
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.
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