10-4 Episode 6: Parallel Extensions

The Discussion

• 

  There is no video this time?

• 

  Only voice?

• 

  same problem here... just voice, no video

• 

  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

• 

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

• 

  (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?

• 

  Again a very interesting video.
  
  Thanks!
  

• 

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

• 

  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.

• 

  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!

• 

  We also dig into the TPL here.
  C

• 

  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.

• 

  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).
  

• 

  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!

• 

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

• 

  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.
  

• 

  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.

• 

  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?
  

• 

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

• 

  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