Parallelism at PDC: Day 0 / overview

The pre-conference session on Concurrency was six hours of good information about what Microsoft is rolling out for parallel programming.

The session was titled "Concurrent, Multi-core Programming on Windows and .NET" and done by David Callahan, Joe Duffy and Stephen Toub.

There were many shameless plugs for a new book by Joe Duffy - made good by giving away books, and demonstrating more than enough competence  with the subject to make the book worth a look.

The session started with David giving us an excellent introduction toe parallel computing.

He started with “the shift to multicore,” and started this with talking about the first 40 years of Moore’s Law.  Yes, an amazing prediction.  This brings up the question - how do you turn cheap processors in to value? He reference an excellent paper by “Moore’s Dividend” by Jim Larus of Microsoft Research (I blogged about this a few months ago).

David talked about the Power-Wall, Memory Wall and ILP Wall – which all lead to the realization that single core performance has all but stopped. David showed a block diagram of the upcoming Intel Larrabee project .

David discussed parallelism with four key points: there will be latent parallelism for future scaling, you should start by focusing on data – the scalable dimension, program using tasks not threads and there is NO silver bullet – many “right” approaches.

David had a nice example program he showed, and talked about the need to understand if you really need to force ordering on data structure access such as walking a graph.  David advocated relaxed sequential ordering.

David defined Parallelism, Concurrency, “multi-threading” – citing a lack of industry standard, but a need for clarity today.

David proposed definitions of:

Concurrent processing: independent requests (most server applications). [simulating isolation of threads]

Parallel processing: decompose one task to enable concurrent execution. [scheduling tasks]

David stressed the need to program in tasks not threads.  Of course, I couldn’t agree more.

David talked about “structured multi-threading” and cited Intel Threading Building Blocks and Cilk Arts as examples of this.  There are “no threads” here and “no concept of processors” here.  The user is abstracted away from mapping of threads onto processors.

David talked about work-sharing and cited OpenMP as an example.

David talked about Dataflow and showed a strassen multiplication (an example of how to do this in TBB can be found in my book on TBB).

David advocated “over-decomposing for scaling” citing it as the new Free Lunch.

David finished up talking about the challenges of scaling (Rabbit Hole of Performance) and debugging a parallel program (Black Hole of Correctness).

David's general treatment of the subject set things up well for Steve to jump in an show us code.

Steve, interestingly, started by showing a demo using threads.

I was surprised – because, while it matched what attendees expect when you talk about parallelism, it directly conflicts with the advice to program in ‘tasks instead of threads’ that David advocated.

Steve was demonstrated the concepts of concurrency, and the various thread controls such as background, interrupt and abort.

Steve then moved on to talk about ThreadPools with QueueUserWorkItem.

After all this, Steve said we DO want to program in tasks instead of threads.

Steve said that an application should NOT do blocking work in the part of the program that has the message loop for handling window events. His example was for “button click” – and the handling (blocking work) should be put off in a thread (use “BeginInvoke()” to run a delegate on the thread pool associated with the window the event is associated with.

Steve demoed coding for “background work and UIs.”  When asked about Silverlight – and confirmed that all this applies with Silverlight as well.  In fact, Steve pointed out that in a browser – it is even more important to do everything asynchronously – so you don’t freeze up Internet Explorer or Chrome – or your browser of choice the Silverlight code is running in.  He said, "Silverlight wants you to do everything asynchronously."

At this point, we broke for lunch.

More about the afternoon session later.