10-4 Episode 6: Parallel Extensions (Channel 9)

In this episode of 10-4, we start taking a look at Parallel Extensions to the .NET Framework. We'll look at some of the surface-area of the Parallel Extensions API and provide you with enough information to start working with it yourself in the Visual Studio 2010 CTP VPC.

Remember that we are running these bits within a virtual machine with a single virtual processor, so you won't be able to see the performance improvements from the library. However, you will be able to start get a feel for the API itself. In future episodes, we will dive into deeper details of the various parts of Parallel Extensions.

Also, in next week's episode, Jonathan Carter will be back to talk about another new feature in ASP.NET 4.0, so make sure to stay tuned for that!

For more 10-4 episodes, be sure to visit:
http://channel9.msdn.com/shows/10-4

Visual Studio Topic Area on Channel 9:
http://channel9.msdn.com/VisualStudio

Visual Studio 2010 CTP VPC:
http://tinyurl.com/GetCTP

Visual Studio 2010 Training Kit
http://tinyurl.com/VS10Kit

Concurrency MSDN Dev Center
http://msdn.microsoft.com/concurrency

10-4! Over and out!

Follow the Discussion

Follow
Oops, something didn't work.

Try again?

Sign In to begin to follow these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.

Getting "follow" information

Stop following these comments

Start following these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.

Removing your "follow"

Setting up your "follow"

Did you know you can
sign up for email notifications?
- Subscribe to these comments

ViktorM

Jan 22, 2009 at 11:58 PM

There is no video this time?
gzpbx

Jan 23, 2009 at 1:17 AM

Only voice?
Yankee

Jan 23, 2009 at 1:18 AM

same problem here... just voice, no video
aL_ Kinect ftw

Jan 23, 2009 at 1:33 AM

as with a bunch of other videos, wmv-high link is dead :/ the silverlight player seems to point to the wma file..

maybe gremlins has invaded the c9 servers :O that would also explain the scilence from the c9 team
Vaso

Jan 23, 2009 at 2:55 AM

I have got video but no voice!! What is going on here Just kidding. WMV (High) is working for me
Raffo

Jan 23, 2009 at 3:31 AM

(same problem here with the missing video, but WMV worked fine.)

Maybe I missed it in the video, but if I got this right, the Parallel.For is the younger (and stronger ) brother of C++ OpenMP ("#pragma omp parallel for"), right? Is there a difference between those two (besides the nice things like a ready-to-use ForEach) or is Parallel basically the .Net port of OpenMP?
Rhapsody In Metal We Trust

Jan 23, 2009 at 5:09 AM

Again a very interesting video.

Thanks!
spivonious

Jan 23, 2009 at 8:18 AM

Are the any differences in the IL code between manually doing the threads and using something like Parallel.For?
JasonOlson

Jan 23, 2009 at 8:53 AM

Sorry all, some of the media links appeared to be messed up. I have added links to the correct media files, so hopefully there shouldn't be a problem anymore.
JasonOlson

Jan 23, 2009 at 8:56 AM

To make a long story short, yes, there's a big difference. When using Parallel.For (and other Parallel Extension constructs), the work will be broken down into Tasks instead of Threads. By using Tasks, the work will use the new work-stealing scheduler under the hood to determine how to properly allocate the work to threads.

So, in short, it's a lot smarter than using Threads directly (as well as more rich and powerful). I'll go into some more details in the future on the work-stealing scheduler and just how this break down into tasks occurs. In the meantime, you can check out the link to the Concurrency MSDN Dev Center to get more information.

Hope this helps!
Charles Welcome Change

Jan 23, 2009 at 1:46 PM

We also dig into the TPL here.
C
JasonOlson

Jan 23, 2009 at 4:58 PM

And I should clarify, it's not so much a difference in the MSIL. Parallel Extensions isn't a compiler feature, it's a library feature. So the MSIL compiled for the code above is still going to be using the Parallel static class, and then the library (implementation of Parallel static class in this case) will break down the work accordingly.
andrgin

Jan 25, 2009 at 5:37 AM

When I simply use the Parallel For loop how does the Parallel library know how many threads it should create at a time.

If you only have code that uses the CPU oder memory it is the number of cores, but what does it when there are more IO operations.

1.) If you have got an application that does CPU calculation 50% of the time and 50% are IO operations like waiting for a another computer in a client/server situation. Then you could use 2 time the amount of cores. If you only have 10% CPU calculations and 90% IO (like a web server or another server application that is most time waiting for the user clients or user inputs). It would not be a good idea to only use 8 threads on a quad with two Quad Core Xeons. You could only have 8 users working on the server at a time. There you should use at least 100 threads.

2.) You could also have a program that calls another program (for example with the shell command and set wait to true). Then you cant know if it is a program that only waits for the user on another client to press the submit button or its an CPU intensive application like my multi core optimized audio encoder that is calling lame on several threads with different files. Then 100 threads would kill the computer if you do not have enough RAM. For the .NET Framework it is an IO operation but in reality it is a CPU only task.

3.) What does the class if you already have multiple threads and each thread does a parallel for loop (take another server where you created the connections with tcplistener.accepttcpclient and started each tcpclient in his own thread. If you have 16 cores and 32 client connections you would make too much connections again. Then you should only use 1 thread per client and if only 1 client is connected then you should use 16 threads.

4.) If I am using an application where the load is on an external network share. How does the .NET Framework know how man parallel operations can be done at once.

I think the parallel for is a good idea but it will never replace manual creation of threads.
Also debugging is more complicated. If I create the thread on my own I can give it a name and find it again very easy. When using network streams I set the threadname to ip and port number (127.0.0.1:4711).
JasonOlson

Jan 25, 2009 at 1:05 PM

I agree andrgin. There will never be a proper replacement for an experienced developer who knows the needs and usage pattern of his application when it comes to concurrency (at least in our current set of tools and languages). However, that doesn't mean that you give up control of threads completely. There are still ways with Parallel Extensions to tell it the proper parameters for your application when it comes to concurrency. it is simply the default that allocates 1 thread/processor.

As far as debugging, the goal is to eliminate the need to debug at the thread level eventually (it obviously won't go away). We recently did a video with Daniel Moth where he shows some of the new debugging tools being integrated in Visual Studio 2010 for making debugging of parallel/concurrent applications easier. You can find it here: http://channel9.msdn.com/posts/VisualStudio/Debugging-Parallel-Applications-with-Visual-Studio-2010/.

As we have to write more and more concurrent applications, the debugging tools in Visual Studio need to be enhanced for this "new world", hence the efforts in the debugging tools space.

So, in short, yes, there is no current replacement for an experienced developer that intimately knows his application's needs for concurrency (usage patterns on the hardware, for instance). But if we can give that developer even more powerful abstractions to deal with and still meet his needs, it becomes very powerful indeed.

Thanks for watching!
esse

Jan 27, 2009 at 3:37 AM

Any chance of getting this in IPOD (MP4) format? Thanks.
andrgin2

Jan 27, 2009 at 12:52 PM

Why dont give you the user more control over the amount of threads. In a for or for each loop you can make an optional parameter with the maximum threadcount. When working with Tasks you could make a property "expected load" where the user can define, how much load can be done at the same time. This gives the user full control but is much easier than making a synchronized Queue with work and start x threads like I did. Synchronized queue has no generic support and I have to build an extra class with all the information the thread needs.
For simple Tasks where each one is doing different work (the same work with only different data is better done with a for each loop I think) the count cant be so big. If there are 20 threads running on a dual core machine this does not kill performance, only if 2K threads are running.
JasonOlson

Jan 28, 2009 at 11:52 AM

andrgin2, this is already possible with the Parallel Extensions. I simply showed "default" behavior in this video.

Most of the parallel operations you can perform with Parallel Extensions provide the ability to specify the "DegreeOfParallelism" which will handle this behavior. So if I was on a 8-core machine, but wanted to leave 2-cores for other work, I could specify a DegreeOfParallelism of 6. This is an easy way for the dev to "throttle" the application when he needs to.

If you need even more fine-grained control, there is a way to create your own TaskManager, not sure you want to go that way though.
VBCoder Waleed El-Badry

May 03, 2009 at 11:56 PM

Hey Jason my Hero,
Since I'm an extermist VB guy, I converted your stunning demo in C# into VB code. How can I post it for VB fans here?
yassir

May 25, 2009 at 5:10 AM

FYI you can't create a Task with Task.StartNew with beta 1 you need to use Task.Factory.StartNew
DFGasner

Jun 01, 2009 at 10:27 AM

I'm very inexperienced with concurrency and parrallel anything, but I do use Background workers to run background tasks and then update my Win GUIs. I'm just wondering if these new parrallel extentions with the Future and For classes add any advantages over using BackgroundWorkers?

Davey