Blog Platform Upgrades Happening this Week

Dear Parallel Computing Enthusiasts,


This week, Microsoft is rolling out a platform update to all blogs on the http://blogs.msdn.com site, including this one.  Comments on this blog will be disabled at approximately 9pm PST tonight and will be off until mid-day on the 24th.  We also do not expect to publish any new blog posts during this time.  If you want to read a bit about some of the platform improvements that will be coming, Sean Jenkin’s blog is a good resource.


Thanks for your patience during this update. See you in a week!

 Blog Platform Upgrades Happening this Week

A Tour of Various TPL Options

The Task Parallel Library (TPL) exposes various options that give you more control over how tasks get scheduled and executed:



  • Choose whether to optimize for fairness or for overheads when scheduling tasks.

  • Specially mark tasks known to be long-running to help the scheduler execute efficiently.

  • Create a task as attached or detached to the parent task.

  • Schedule continuations that run if a task threw an exception or got cancelled.

  • Run tasks synchronously.

Joseph E. Hoag’s article A Tour of Various TPL Options explains these options in detail, accompanied by examples of correct and incorrect uses.


(This paper and many more are available through the Parallel Computing Developer Center on MSDN at http://msdn.microsoft.com/en-us/concurrency/ee851578.aspx.)

 A Tour of Various TPL Options

ParallelExtensionsExtras Tour – #9 – ObjectPool<T>

An object pool is a mechanism/pattern to avoid the repeated creation and destruction of objects.  When code is done with an object, rather than allowing it to be garbage collected (and finalized if it’s finalizable), you put the object back into a special collection known as an object pool.  Then, when you need an object, rather than always creating one, you ask the pool for one: if it has one, it gives it to you, otherwise it creates one and gives it to you.  In many situations where creation and destruction is expensive, and where many objects are needed but where only a few at a time are needed, this can result in significant performance gains.


Object pools are just as relevant in multi-threaded scenarios as they are in single-threaded scenarios, but of course when dealing with multiple threads, you need to synchronize correctly (unless a separate pool is maintained per thread, in which case you’re trading synchronization cost for potentially creating more objects than you otherwise would).  ParallelExtensionsExtras contains a simple ObjectPool<T> implementation in the ObjectPool.cs file, built on top of IProducerConsumerCollection<T>.


The implementation in ParallelExtensionsExtras is slightly more complex than what we’ll show here, which is just the basic essence of the type (the implementation in ParallelExtensionsExtras also implements IProducerConsumerCollection<T> and provides some useful additional helper methods).


public sealed class ObjectPool<T>


{


    private readonly Func<T> _generator;


    private readonly IProducerConsumerCollection<T> _objects;


 


    public ObjectPool(Func<T> generator) :


        this(generator, new ConcurrentQueue<T>()) { }


 


    public ObjectPool(Func<T> generator,


        IProducerConsumerCollection<T> collection)


    {


        if (generator == null)


            throw new ArgumentNullException(”generator”);


        if (collection == null)


            throw new ArgumentNullException(”collection”);


        _generator = generator;


        _collection = collection;


    }


 


    public void PutObject(T item) { _objects.TryAdd(item); }


 


    public T GetObject()


    {


        T value;


        return _objects.TryTake(out value) ? value : _generator();


    }


}


 


The constructors initialize the pool with the generator function to use for creating objects when the pool is empty as well as a collection used to store all of the pooled objects.  The PutObject method simply adds the object into the collection. The GetObject method tries to take an object from the collection and return it, returning a newly generated object instead if nothing could be retrieved from the collection.


Note that an instance of this ObjectPool<T> type may be used from multiple threads concurrently, and all of the synchronization is handled automatically by the IProducerConsumerCollection<T> implementation.

 ParallelExtensionsExtras Tour   #9   ObjectPool<T>

Visual Studio 2010 and the .NET Framework 4 are now available!

As announced here, Visual Studio 2010 and the .NET Framework 4 are available!  This includes the exciting support for parallel computing that we’ve been talking about for quite some time now.  For an overview of what’s new for developers with managed code, both in terms of frameworks and tools, check out this new article on DevProConnections: Parallel Computing with the .NET Framework 4. Visual Studio 2010 and the .NET Framework 4 are now available!

Want to work on Parallel Computing?

We’re hiring! If you’re reading this post, you most likely have an interest in parallel or distributed computing, writing concurrent software, and the like.  Take that interest a step further, and help us make the manycore era a successful reality by coming to work on the Parallel Computing Platform team at Microsoft.

We currently have several exciting positions available:

If you’re interested in any of these, please submit your resume and apply for the job through the "Apply to Job" button on the relevant page. We look forward to hearing from you!

 Want to work on Parallel Computing?

FAQ :: Which .NET language is best for parallelism?

The new parallelization support in the .NET Framework 4 is implemented purely in libraries and the runtime and does not require special compiler support.  Therefore, it is available to all compliant .NET languages.  This includes all of the managed languages that ship as part of Visual Studio 2010 (Visual C#, Visual Basic, Visual F#, and C++/CLI) as well as other Microsoft-provided languages (e.g. IronPython) and 3rd-party developed languages.  In fact, our samples available at http://code.msdn.microsoft.com/ParExtSamples include examples in multiple languages.


However, some of the APIs in .NET 4 have been designed with certain language capabilities in mind.  For example, C#, Visual Basic, and F# all support lambda expressions and closures, which enable easily defining the bodies for Tasks and parallel loops.  Query comprehensions in C# and Visual Basic, and sequences in F#, can help to write cleaner, more elegant PLINQ queries.  F#’s support for asynchronous workflows and its provision of immutability of data by default are geared towards making it easier to write highly concurrent applications.


In summary, you can introduce parallelism in your application using any .NET language.  Which one is best still depends on your scenario.

 FAQ :: Which .NET language is best for parallelism?

Are you using the CCR? We’d love to hear about it.

Are you using the CCR (Microsoft Robotics’ “Concurrency & Coordination Runtime”) today in production applications or libraries, and in particular for non-robotics purposes?  If so, we’d love to hear about your experiences, and any and all information you’re willing to share would be very welcome. 


What do you like about it and the programming model it employs?  What don’t you like about it?  What features are crucial to you, and what features do you never use? How are you architecting your applications with it?  Any key code samples that are representative of your application you’d like to share, or even better, a standalone implementation that highlights how you use it?  If you experiemented with it but ended up not using it, why? Etc. If you’re interested and willing to share, please send me an email at stoub at microsoft dot com.


We’re excited to hear from you!


Thanks,
Stephen

 Are you using the CCR? Wed love to hear about it.

FAQ :: You talk about performance, speedup, and efficiency…what do you mean exactly?

All of these terms are overloaded, even in the context of parallel computing.  However, we’ve used them extensively to describe how well our parallel algorithms and demo applications work.  And sometimes, we throw them around carelessly on the blog, forums, etc., so here are our general definitions.


Performance is an attribute that refers to the total elapsed time of an algorithm’s execution.  Less elapsed time means higher performance.


Speedup is a metric that quantifies performance by comparing two elapsed time values.  In parallel computing, these two values are usually generated by the execution of a serial algorithm and a parallelized version of the same algorithm.  Speedup is then calculated using the following equation:


Speedup = Serial Execution Time / Parallel Execution Time


So if a serial algorithm takes 100 seconds to complete, and the parallel version takes 40 seconds, the speedup is “2.5x”.


Efficiency is a metric that builds on top of speedup by adding awareness of the underlying hardware.  It is usually calculated using the following equation:


Efficiency = Speedup / # of cores


So if speedup is “2.5x” on a 4-core machine, efficiency is 0.625 or 62.5%.


Scalability is an attribute that refers to the speedup of an algorithm given different numbers of cores/processors.  The efficiency metric is good for quantifying scalability, because if efficiency holds constant as the number of cores changes, we have linear scaling (or awesome scalability).

 FAQ :: You talk about performance, speedup, and efficiency…what do you mean exactly?

FAQ :: The Debugger does not correctly handle Task exceptions?

The following code correctly observes and handles a Task exception and should print “gotcha!” to the console.  By default though, the Debugger will report a crash.

Task t = Task.Factory.StartNew(() => { throw new Exception(“poo”); });


try { t.Wait(); }


catch (AggregateException) { Console.WriteLine(“gotcha!”); }



The issue has to do with the “Just My Code” mode (enabled by default), which causes the Debugger to break in immediately when an exception leaves user code (the Task delegate) and enters non-user code (TPL internal).  This is usually a good thing, because it allows you to pinpoint exactly where an exception is going unhandled.  However, in this case, the Debugger is breaking before TPL can observe the exception.


Running without debugging or disabling “Just My Code” (Tools -> Options -> Debugging -> General) should resolve the issue.  Also, note that the Debugger actually broke in as though it had hit a breakpoint, so Continuing (F5) or Stepping (F10/F11) should allow further execution.


Just My Code Mode

 FAQ :: The Debugger does not correctly handle Task exceptions?

Debugging TPL apps in VS2010

The new parallel debugger windows in Visual Studio 2010 (Parallel Tasks and Parallel Stacks) have had many fixes and updates.


I have refreshed the existing content and also added new material for Beta 2. Find links to all of it from my blog post on Parallel Debugging.


Cheers
Daniel

 Debugging TPL apps in VS2010


Older entries » »