Visual Studio 2010 will bring a new focus on profiling and debugging parallel applications. One of the primary issues they are trying to address is the black box between source code at design time and the code at runtime. At design time the code is presented in a declarative fashion using PLINQ or Parallel.For, while at run time it is seen in terms of individual threads. What happens between those two layers is a deep mystery as far as the debugger is concerned. To address this Microsoft wants to move the debugger's focus to a higher level of abstract, namely the task level.
To understand how this will work, it is important to understand that both PLINQ and Parallel.For are built on the Task Parallel Library. Though grossly simplified, one can think of a parallel operation as a collection of Tasks, which in turn are run on top of a collection of threads.
To see what is happening in a task in today's VS, the developer needs to check each thread individually. With VS 2010, a new window shows tasks directly. Each task is shown as a box containing its call stack and the arguments passed in. Multiple tasks sharing a common call stack will be listed in the same box. If tasks have a common base but diverge further down in the call stack, they are shown as a common box with separate child boxes hanging off them.
Instead of stacks, one can also look at a method view. This focuses on a given method regardless of how it is called, with parent and child boxes for each method that calls or is called by the selected method.
A separate view shows how tasks are related to the child tasks it created. By default this is a hierarchal grid with information such as whether or not the task has been started and what it is waiting on. Grouping and sorting by any column is allowed.
On the profiling front, three new tools are being presented. The first is a trace that shows CPU utilization on a pre-core basis. For each time slice a stacked bar shows how many cores were used by the application, idle, or used by other system processes. This allows developers to quickly see whether or not an application is consuming all the resources offered to it.
The next tool shows a timeline for each thread. At any given point the call stack and delay times for the thread is available. Delays are grouped by type such as code execution, waiting for a lock, or waiting on IO. When using constructs like Parallel.For, markers will indicate when the parallel loop started and finished.
The third shows how threads are mapped to cores. Displayed in a time-line fashion, one can quickly see if the color-coded threads are migrating from core to core or are being context-switched too often. This is important because every time a thread jumps to a different core there is a good chance the high-speed caches in the CPU will be invalidated.
Steve Teixeira, Daniel Moth, and Sean Nordberg presented these features in a Channel 9 video.