10-4 Episode 6: Parallel Extensions

Posted By: Jason Olson | Jan 22nd @ 6:18 PM | 74,911 Views | 20 Comments

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!
Media Downloads:
Rating:
3
1
#Jan 23rd @ 8:56 AM
JasonOlson
JasonOlson
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!
#Jan 23rd @ 1:46 PM
Charles
Charles
Welcome Change
We also dig into the TPL here.
C
#Jan 23rd @ 4:58 PM
JasonOlson
JasonOlson
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.
#Jan 25th @ 5:37 AM
andrgin
andrgin
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).
#Jan 25th @ 1:05 PM
JasonOlson
JasonOlson
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!
#Jan 27th @ 3:37 AM
esse
esse
Any chance of getting this in IPOD (MP4) format? Thanks.
#Jan 27th @ 12:52 PM
andrgin2
andrgin2
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.
#Jan 28th @ 11:52 AM
JasonOlson
JasonOlson
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.
#May 3rd @ 11:56 PM
VBCoder
VBCoder
Waleed El-Badry
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?
Microsoft Communities