Blog Platform Upgrades Happening this Week

16.05.2010 at 10:05 pm · Saved under .NET Help

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 24^th.  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!

Comments closed

ThreadPool performance you can see

14.04.2010 at 1:06 am · Saved under .NET Help

We’ve spent a lot of time touting improvements to the .NET Framework in .NET 4 around threading, including core enhancements to the performance of the runtime itself.  Sometimes data is more powerful than words, however, and it’s useful to be able to see exactly what kind of difference such improvements can make.  To assist with that, here is code for a small sample you can try compiling and running on your own:

using System;

using System.Diagnostics;

using System.Threading;

class Program

{

    static void CreateAndWaitForWorkItems(int numWorkItems)

    {

        using (ManualResetEvent mre = new ManualResetEvent(false))

        {

            int itemsRemaining = numWorkItems;

            for (int i = 0; i < numWorkItems; i++)

            {

                ThreadPool.QueueUserWorkItem(delegate

                {

                    if (Interlocked.Decrement(

                        ref itemsRemaining) == 0) mre.Set();

                });

            }

            mre.WaitOne();

        }

    }

}

The CreateAndWaitForWorkItems method simply launches N work items using ThreadPool.QueueUserWorkItem and then waits for all N to complete by atomically decrementing a shared counter.  The main method then times the invocation of this method with N equal to 10 million, doing so several times and taking the average.  This microbenchmark is pure overhead, as there’s no actual work being performed in each work item. In fact, we should expect that as we add more cores, the time to complete this operation will increase, as more cores will contend for the data structures employed in both the ThreadPool and in my simple test. The hope is that the work done in .NET 4 decreases that overhead, especially on higher core counts where more and more threads will be contending for the shared data structures employed.

The following numbers are in no way official benchmarks, but they can give you a sense for how the work that’s been done in .NET 4 really does make a difference. These are the numbers I see when I run this microbenchmark informally on .NET 3.5 and on .NET 4 on two laptops I currently have access to while writing this blog post.  The only change I made to go from .NET 3.5 to .NET 4 was modifying the “Target framework” in the project’s properties in Visual Studio, taking advantage of Visual Studio 2010’s multitargeting support.

Some pretty awesome performance improvements simply by upgrading to .NET 4.

Comments closed

Want to work on Parallel Computing?

13.02.2010 at 8:12 pm · Saved under .NET Help

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:

• Program Manager
• Software Development Engineer Lead
• Software Development Engineer in Test

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!

Comments

Gallery of Processor Cache Effects

08.02.2010 at 10:40 am · Saved under .NET Help

Igor Ostrovsky is a developer on the Parallel Extensions team.  On his blog, he’s documented a great set of examples for how caches can effect application performance; this is important to think through when writing parallel applications, but as Igor demonstrates, it applies equally to serial applications.  Check out his post.

Comments

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

29.01.2010 at 8:39 pm · Saved under .NET Help

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

Comments

Updated Parallel Computing Developer Center on MSDN

03.12.2009 at 7:10 pm · Saved under .NET Help

Check out the updated Parallel Computing Developer Center on MSDN.  Both the look and the content have been revised significantly…

Enjoy!

Comments

Attending PDC09? Meet with the Parallel Computing Platform team.

02.11.2009 at 8:55 pm · Saved under .NET Help

Are you attending PDC09?  Want to meet with members of the Parallel Computing Platform team?  See http://blogs.msdn.com/visualizeparallel/archive/2009/11/02/the-parallel-computing-platform-team-pcd-09.aspx for more details.

Comments

Samples for Parallel Programming with the .NET Framework 4 Beta 2

02.11.2009 at 1:27 pm · Saved under .NET Help

We’ve posted a whole bunch of samples on Code Gallery showcasing how to use the new parallelism support in the .NET Framework 4.  You can find them at http://code.msdn.microsoft.com/ParExtSamples.  Enjoy!

Comments

Parallelism Talks at PDC09

23.10.2009 at 7:47 pm · Saved under .NET Help

If you’re going to PDC this year, we have four great talks on parallelism coming you’re way and, if you’re not, may we suggest you sign up?

We don’t have the exact dates of the talks yet (we’ll let you know when we do) but here are the talks you won’t want to miss!

Patterns of Parallel Programming: A Tutorial on Fundamental Patterns and Practices for Parallelism
(by Richard Ciapala, Ade Miller, Herb Sutter, and our very own Stephen Toub)
A workshop for experienced developers who are relatively new to parallel computing.  Learn how established software patterns can help you build on Microsoft’s Parallel Computing Platform (including deep dives into TPL and PLINQ).

PLINQ: LINQ, but Faster!
(by Igor Ostrovsky and Ed Essey)
Our very own Igor and Ed dive deep into PLINQ via Visual Studio 2010.  See what it looks like from the perspective of LINQ developers, the debugging and profiling support, how it’s implemented under the covers, and how to best incorporate it into your applications in order to reap the performance benefits of the manycore era.

The State of Parallel Programming
(by supercomputing luminary Burton Smith)
A “relatively recent consensus view about what is needed for productive parallel programming, and why.”

F# for Parallel and Asynchronous Programming
(by Luke Hoban)
Luke will take you through the core concepts of the F# language and show you how ideas like immutability, functional design, async workflows, agents, and more can be used to meet the challenges of today’s real-world applications.

Have fun!

Josh Phillips | Program Manager | Parallel Computing Platform |Microsoft

Comments

Task Scheduler From Current Synchronization Context

22.09.2009 at 11:46 am · Saved under .NET Help

The Task abstractions in .NET 4 run on instances of the TaskScheduler class.  Two implementations of TaskScheduler ship as part of the .NET Framework 4.  The first is the default scheduler, which is integrated with the .NET 4 ThreadPool and takes advantage of its work-stealing queues.  The second is the type of TaskScheduler returned from the static method TaskScheduler.FromCurrentSynchronizationContext.

According to MSDN, SynchronizationContext “provides the basic functionality for propagating a synchronization context in various synchronization models.”  What does that really mean?  At its core, SynchronizationContext provides two methods, Send and Post, both of which accept a delegate to be executed.  Send synchronously invokes the delegate, and Post asynchronously invokes the delegate.  That’s it, and the base implementation of SynchronizationContext doesn’t do anything fancier than that:

public virtual void Send(SendOrPostCallback d, object state)
{
d(state);
}

public virtual void Post(SendOrPostCallback d, object state)
{
ThreadPool.QueueUserWorkItem(new WaitCallback(d.Invoke), state);
}

Where things get interesting is when new types are derived from SynchronizationContext, something typically done by a UI framework (though there are other non-UI framework implementations).  For folks familiar with Windows Forms and Windows Presentation Framework development, you’re likely aware that UI controls should only be accessed by the thread that created them, almost always the main UI thread.  Thus, if a thread doing work in the background wants to update something in the UI, it needs to marshal that work back to the GUI thread so that the controls may be accessed safely.  Different UI frameworks expose different ways for accomplishing this marshaling.  For example, in Windows Forms, one uses the Invoke or BeginInvoke method of the target Control (or at least a Control created on the same thread as the target Control).  In WPF, one uses the target thread’s Dispatcher and corresponding Invoke/BeginInvoke  methods.  With every UI framework having its own model for marshaling work to a particular “synchronization context”, it becomes difficult to write code that supports this marshaling concept but which is agnostic to the particular environment that it’s in.  Enter SynchronizationContext.  A new type may be derived from SynchronizationContext such that its Send method synchronously marshals a delegate to the right thread for execution, and Post does the same but asynchronously.  If you look at the implementations of the SynchronizationContexts provided by Windows Forms and WPF, that’s exactly what they do, delegating to the relevant Invoke/BeginInvoke methods from Send and Post to marshal the work correctly.

To make it easy to get at the right SynchronizationContext, a UI framework like Windows Forms will publish an instance of its SynchronizationContext-derived class to SynchronizationContext.Current.  Code can then grab SynchronizationContext.Current and use it to marshal work, without having to know whether it’s being used from Windows Forms or Windows Presentation Foundation or another similar model.

“TaskScheduler.FromCurrentSynchronizationContext” should now make more sense.  This method creates a TaskScheduler that wraps the SynchronizationContext returned from SynchronizationContext.Current.  Thus, this gives you a TaskScheduler that will execute Tasks on the current SynchronizationContext.  Why is that useful?  It means you can create Tasks that are able to access UI controls safely, simply by running them on the right scheduler.

Let’s say that I wanted to load three images from some data source.  When those images have been loaded, I want to blend them all together, and then I want to display the result into a PictureBox on my UI.  Using Tasks and TaskScheduler.FromCurrentSynchronizationContext, I could write code like the following:

private void Button1_Click(…)
{
var ui = TaskScheduler.FromCurrentSynchronizationContext();
var tf = Task.Factory;

// Load the three images asynchronously
var imageOne = tf.StartNew(() => LoadFirstImage());
var imageTwo = tf.StartNew(() => LoadSecondImage());
var imageThree = tf.StartNew(() => LoadThirdImage());

// When they’ve been loaded, blend them
var blendedImage = tf.ContinueWhenAll(
new [] { imageOne, imageTwo, imageThree }, _ =>
BlendImages(imageOne.Result, imageTwo.Result, imageThree.Result));

// When we’re done blending, display the blended image
blendedImage.ContinueWith(_ =>
{
pictureBox1.Image = blendedImage.Result;
}, ui);
}

This code runs three tasks to load the three input images asynchronously.  When all of those have been loaded, again asynchronously some BlendImages method is used to blend the images, taking the three inputs and returning the blended image.  Finally, once that’s done, another task is used to render the blended image by storing it into a PictureBox on the UI.  Since this modifies a UI control, we need to do it from the UI thread.  Thus, we pass a TaskScheduler to the ContinueWith method; this scheduler targets the UI’s SynchronizationContext, and will cause the Task to execute on the UI thread.

TaskScheduler.FromCurrentSynchronizationContext is provided for convenience and because this is a very common need.  However, due to TaskScheduler’s extensibility, it’s actually possible to implement this behavior yourself, and in doing so you could modify it to suit your own needs however you see fit.

Let’s say you did want to develop a new SynchronizationContextTaskScheduler.  It might look something like this:

public class SynchronizationContextTaskScheduler : TaskScheduler
{
private ConcurrentQueue<Task> _tasks = new ConcurrentQueue<Task>();
private SynchronizationContext _context;

public SynchronizationContextTaskScheduler() :
this(SynchronizationContext.Current) { }

public SynchronizationContextTaskScheduler(
SynchronizationContext context)
{
if (context == null) throw new ArgumentNullException(”context”);
_context = context;
}

protected override void QueueTask(Task task)
{
// Add the task to the collection
_tasks.Enqueue(task);

// Queue up a delegate that will dequeue and execute a task
_context.Post(delegate
{
Task toExecute;
if (_tasks.TryDequeue(out toExecute)) TryExecuteTask(toExecute);
}, null);
}

protected override bool TryExecuteTaskInline(
Task task, bool taskWasPreviouslyQueued)
{
return SynchronizationContext.Current == _context &&
TryExecuteTask(task);
}

public override int MaximumConcurrencyLevel { get { return 1; } }

protected override IEnumerable<Task> GetScheduledTasks()
{
return _tasks.ToArray();
}
}

Not a lot of code for a fairly powerful thing.

• The constructors simply accept the target SynchronizationContext and store it, also initializing a thread-safe queue that will store the tasks to be executed.
• The QueueTask method is called whenever the system is providing a Task for this scheduler to execute: this scheduler handles it by storing that Task into a queue, and then Post’ing to the SynchronizationContext a delegate that will pull the next Task from the queue and execute it.
• The TryExecuteTaskInline is invoked any time the system wants to run a Task inline on the current thread (either from a call to RunSynchronously or from a Wait attempt): we need to make sure that the call is coming from the same SynchronizationContext as the target, otherwise we may end up running in the wrong context.
• We only intended to support SynchronizationContexts that represent a single thread of execution (that’s most common), so we return 1 from MaximumConcurrencyLevel.
• And we want the debugger to be able to display tasks scheduled to this scheduler, so we override GetScheduledTasks to return an array of the tasks queued. (This is why we need to explicitly store the queue of tasks; otherwise, we could have simply relied on lambda closures to capture each task to be executed.)

Comments