The Moth

Updated Beta1 slides for parallelism

noreply@blogger.com (The Moth) — Thu, 02 Jul 2009 18:56:00 PDT

For those of you interested in my session on parallelism with VS2010, I gave an extended/longer version of it recently and included a bunch of new slides and updated the existing ones to match the recent release of VS2010 Beta1. Get the updated pptx here (checkout the annotated slides 16 and 17 on Parallel Tasks and Parallel Stacks).

Debug .NET dumps with VS2010

noreply@blogger.com (The Moth) — Thu, 02 Jul 2009 18:45:00 PDT

Tess has written a great post on debugging .NET dumps in Visual Studio 2010 (which also briefly touches on the Parallel Stacks window ;-)

yearsOnThisPlanet++

noreply@blogger.com (The Moth) — Thu, 02 Jul 2009 18:39:00 PDT

Today I am one year older (but not wiser ;-). This time last year I got an SSN and had almost no friends in the USA, while this year I've booked a bar to host the many cool people I've met here. If you are in Seattle and coming to my party, it's gonna be messy so come prepared ;-)

Parallelism in VS2010 at Illinois next week...

noreply@blogger.com (The Moth) — Sat, 20 Jun 2009 06:52:00 PDT

The University of Illinois at Urbana-Champaign is holding what seems like a fantastic week-long summer course on multi-core programming. They have invited me to give a session (or what they term on that page a "special lecture") on Parallel Programming in Visual Studio 2010! All I have to do this weekend is prepare that lecture :-)

On a personal note, I've never been to that part of the USA, so I'll spend a couple days in Chicago finding out if all the rumors (good and bad) are true…

Parallel Stacks and Parallel Tasks screencasts

noreply@blogger.com (The Moth) — Wed, 17 Jun 2009 16:52:00 PDT

Whether you have read or not my blog posts on the new Visual Studio 2010 debugger windows, you now have the option of seeing them in action in these videos I published on channel9: 17-minute screencast on Parallel Stacks and 14-minute screencast on Parallel Tasks.

If you don't like watching videos and you don't like reading about features, maybe you prefer the guided hands on approach. Launch your VS2010 instance and go through my walkthrough published on MSDN.

Parallel Stacks – Method View

noreply@blogger.com (The Moth) — Sat, 06 Jun 2009 15:24:00 PDT

The new Parallel Stacks window has a special feature (that applies to both Threads View and Tasks View) that we call Method View. It is accessible from the toolbar and it acts on the current stack frame (i.e. the only one with a green arrow icon or, in the absence of that, the one with the yellow arrow). It takes that method and pivots the diagram on it, coalescing all occurrences of that method into a single node in the center, clearly showing the callees and the callers. Threads that do not have that method on their stack are filtered out and not shown. Check out the before and after screenshots:

Switching to another stack frame in Method View will result in that method context becoming the "center of attention", and hence potentially some threads will disappear and others will re-appear on the diagram. The view persists cross debugging sessions (just like all the other options) and to get out of it you simply need to click on the Method View toolbar button again and return to Stack View.

Parallel Stacks – Tasks view

noreply@blogger.com (The Moth) — Wed, 27 May 2009 16:12:00 PDT

This blog post presumes you read my posts on Parallel Tasks and on Parallel Stacks, which describe the usefulness of the new VS2010 debugger windows for debugging multithreaded applications. In today's post I'll expand on the task-specific support in the Parallel Stacks window: we call this the Tasks View of the Parallel Stacks window and you can switch to that view from the combobox in the toolbar.

Threads versus Tasks
For the purposes of this window, there are 3 main differences when you are looking at call stacks of threads versus call stacks of tasks:

1. Some threads in your application will be running tasks and others will not.
2. A thread could be running more than 1 Task (only the task at the top part of the thread's call stack is actually running, you can assert that the other(s) would be in a waiting state).
3. Call stacks of threads are mapped back to the thread via the Thread ID; call stacks of tasks should be mapped back to the task via the Task ID.

These 3 differences map to the following 3 observations of what you see in the Tasks View of the Parallel Stacks window (compared to the separately covered Threads View of the Parallel Stacks window):

a) We don’t show the threads not executing tasks.
b) We split call stacks of threads executing multiple tasks into separate nodes, so you can clearly see each task call stack separately.
c) The tooltip of the header in the node and on each method context (displaying the stack frames) shows task IDs instead of thread IDs.

Here is an example where one thread is not running tasks (the Main thread):

Trimming frames from the bottom
You will notice in the screenshot above another difference not mentioned so far: some stack frames at the root of the call stack are trimmed. This is what I call showing the "real" call stacks of tasks. If you think about it, your code created a task pointing it to a method and it is from somewhere close to that method that you want to start looking at the call stack. All the other (typically non-user code) stack frames at the root of the thread's call stack are not of interest in this Tasks View, so we trim them out (as per screenshot above).

Trimming frames from the top
We also trim stack frames from the top of the call stack. The consistent decision could have been to trim *all* non-user code at the top since that is not code you would typically care too much about when debugging tasks. However, what is interesting in many scenarios is the first non-user method that was called from the top most user frame – so we kept that one frame and trimmed all the ones above it.

Here is an example of trimming stack frames from the top and also of a thread running 2 tasks:

"Go To Thread" and "Go To Task" menu
Before anyone panics with the stack trimming I mentioned above, remember that you can always view entire thread call stacks in this window by switching to the Threads View. In fact, we made it even easier to switch not just view, but also scroll to the exact position you want by offering a menu item (you'll recall I left that out from my context menu description last time) that switches views and scrolls to the same stack frame you are looking in the other view.

Status on header tooltip
I mentioned the method context tooltip showing task IDs instead of thread IDs and you can see that in the screenshot below. I also mentioned the header tooltip showing task IDs instead of thread IDs; for this tooltip we threw in bonus information by showing you the Status of each task

Feedback Please
Start playing with Visual Studio Beta 1 and let me have it!

Parallel Stacks – another new VS2010 debugger window

noreply@blogger.com (The Moth) — Wed, 20 May 2009 13:19:00 PDT

Assumed knowledge aka Background Reading
It is important to understand some of the existing Call Stack window features. Even if you don't care about this VS2010 feature, you can improve your debugging skills with any version of Visual Studio by reading that blog post.

Parallel Stacks debugger toolwindow
With applications increasingly having more than one thread and with parallelism gaining momentum, we need the ability to view (and navigate) more than 1 call stack from a single view. Previously I discussed the motivation behind this new window here, and I'll use the exact same code for the following screenshots. Here is the new Parallel Stacks window:

In the picture above you can see the call stacks of 3 threads in a single view. The way you read this picture is that you have one thread that went from Main to A to B. Two other threads started from the same external code and then went to A, but one of them continued to B and then to some external code, and the other continued to C and then some AnonymousMethod. This is also the active stack frame and this is the current thread.

Toolbar buttons from left to right
Threads/Tasks combobox: Switches the view between showing call stacks of threads to showing call stacks of Tasks (and vice versa). More on the Tasks view of the Parallel Stacks window in another post.

Show Only Flagged: Shows call stacks only for the threads that are flagged in the Threads window.

Toggle Method View: Switches between normal view and method view. Method view will be the subject of a separate post.

Toggle TopDown/BottomUp Display: By default stacks are drawn bottom up (so the frame at top of stack appears at the... top). This button allows drawing the diagram top down, more like a call graph.

Auto Scroll To Current Stack Frame: Auto-scrolls the diagram so the current stack frame is in view. Useful in large diagrams when changing the current stack frame via other windows or when hitting a new breakpoint.

Toggle Zoom Control: Shows or hides the zoom control. Note that zooming is always available via Ctrl+mousewheel.

Context Menu Items in random order
The last 5 menuitems are borrowed directly from the Call Stack window and introduce no new behaviors: Go To Source Code, Go To Disassembly, Show External Code, Hexadecimal Display, Symbol Load Information and Symbol Settings.

Go To Task (Thread): This performs the same function as the combobox on the toolbar does, but additionally keeps the same stack frame highlighted. It will be discussed in a separate post.

Switch To Frame: Same as menuitem on Call Stack window. Additionally, with Parallel Stacks, multiple frames may correspond to a method context so the menuitem has submenus, each representing a specific stack frame. If one of the stack frames is on the current thread (so by definition you are clicking on a node with a blue highlight around it) then that stack frame has a checkmark in front of it. For example, right clicking on Program.A and expanding the first menuitem results in this screenshot:

Annotations and Elements Listed
Call Stack Segment or Node: Each "box" contains a series of method contexts for one or more threads. If the node has no arrow lines connected to it, then it represents the entire call path for the thread(s), otherwise you need to follow the arrows to piece together the entire call path of a thread.

Blue Highlight: The blue highlight indicates the call path to which the current thread belongs to.

Arrow lines: Arrow lines connect nodes to make up the entire call path for the thread(s).

Tooltip on Node Header: The tooltip on each node shows the ID(s) of the thread(s) relevant to the node.

Method Context: Represents one or more stack frames in the same method.

Tooltip on method context: The tooltip on each method context shows the full details of all the stack frames it represents. If one of the stack frames is also on the current thread, it is shown in bold font.

Yellow Arrow Icon: A yellow arrow in front of a method context indicates that the active stack frame of the current thread is in that method context. As you'd expect, this icon would appear only at the last frame in a node that also has the blue highlight around it.

Cloth Threads Icon: A cloth threads icon in front of a method context indicates that the active stack frame of a non-current thread is in that method context. As you'd expect, this icon would appear only at the last frame in a node and there would be no blue highlight.

Green Arrow Icon: A green arrow in front of a method context indicates that the current stack frame is in that method context. That method context is also in bold font, and as you'd expect is in a node with a blue highlight. If the method context appears in other places/nodes on the diagram, it is bolded there too. E.g., if in the context menu shown above, we clicked on menuitem '5744: Program.A("hi") Line 23' we would be switching thread and current frame on that thread with a single action, resulting in the picture looking like this:

Navigation Aids
Bird's Eye View: When there are scrollbars present, the space between the scrollbars reveals a button that when pressed shows a thumbnail view of the picture which you can use to quickly scroll around it.

Zoom Control: The zoom control lets you zoom in and out, zoom to fit and zoom to 100%.

Panning: Pressing the mouse button on any white space and dragging, will scroll the diagram.

Call to Action
The call to action is identical to the Call to Action of my post on Parallel Tasks. Read it and come back here to comment ;-)

VS2010 fix for "not all anonymous methods are the same"

noreply@blogger.com (The Moth) — Tue, 19 May 2009 12:56:00 PDT

Last September (wow, time flies!) I blogged about a VS2008 issue described as: Not all AnonymousMethods are the same. My team fixed this, so let's revisit the equivalent code from that post, this time in VS2010. The screenshot tells the story:

Notice that anonymous methods now have a suffix? This tells you immediately that the 2 threads are not at the same method. The information becomes even clearer with a new debugging window we are introducing in VS2010 that I will describe in my next post: Parallel Stacks.

Tasks documentation

noreply@blogger.com (The Moth) — Tue, 19 May 2009 08:11:00 PDT

Interested in the System.Threading.Tasks namespace? Read here the official MSDN documentation.

Parallel Tasks – new Visual Studio 2010 debugger window

noreply@blogger.com (The Moth) — Fri, 15 May 2009 02:55:00 PDT

Assumed knowledge aka Background Reading
.NET 4 introduces a new class that lives in mscorlib that I have blogged about before: System.Threading.Tasks.Task, which as you'll recall is also what Parallel.For depends on. Collectively, all those new classes is what we refer to as Task Parallel Library and the team that owns it has blogged what is new for TPL in Beta1. Another .NET 4 feature I blogged about before also depends on Tasks for its implementation: Parallel LINQ. The same team owns that and there is a blog post of what is new for PLINQ in Beta1.

If you are a C++ developer, then you'll be happy to know that the task concept also exists in C++ version 10 that ships with VS2010. In addition to the dedicated native concurrency blog I just linked to, there is a ch9 video on the topic.

Parallel Tasks debugger toolwindow
To support the new task-based programming model introduced with Visual Studio 2010 for both managed and native developers, we are introducing a new debugger window: Parallel Tasks. You can open it after you hit a breakpoint, via the same location where all debugger windows live.

Sorting, Reordering, Hiding/Showing columns
Columns are re-orderable (by dragging them left/right) and sortable (by clicking on them) as indicated by the little triangle, which also shows the sort direction. You can also hide or show columns by right clicking on any column and then (un)checking the column menuitem of interest

Grouping on a column
Via the context menu shown above you can group on your column of choice. What is cool about grouping is that it allows you to flag an entire group with one click (more on flagging later), it allows you to collapse the group (preserved between debugging steps) and it shows a count of the items in the group (even when it is collapsed).

Description of the 8 Columns
- Flag Column: Each item can be in a flagged or non-flagged state (the default). You can toggle the state of a row by clicking on the corresponding cell. You would do this to make it easier to keep an eye on an item of interest between debugging steps (e.g. breakpoints, F11) or to flag multiple items and then sort on the column to bring them all to the top. Flagging is not persisted between debugging sessions. Another use of flagging is to filter the task call stacks shown in the new Parallel Stacks window, but that is a topic of another blog post.

- Icon Column: This column is blank by default except for one Task which will have a yellow arrow in this cell. The yellow arrow indicates which one is the current task. The current task is one which is executing on the current thread and whose top stack frame is the current frame. Another icon that can be displayed in this column is the "pause" icon to indicate a frozen thread (more on freezing further down).

- Id: Each Task has a unique Id which can be retrieved programmatically by calling the Id property (for C++ tasks, this will be the memory address). This is useful so you can map the task you are seeing in the window with diagnostic output you may send to some stream; it is also useful for cross-referencing tasks between the Parallel Tasks and the Parallel Stacks windows (which I'll describe in another post).

- Status: The 4 potential values here are Running, Scheduled, Waiting and Waiting-Deadlocked. "Running" are the tasks that are executing code at the moment your app breaks in the debugger (they are at top of stack of a running thread); "Scheduled" are the ones that are sitting in some queue but have not been executed by a thread yet; "Waiting" are the ones that have run, but are now blocked on something, e.g. a Monitor, a critical section; "Waiting-Deadlocked" are the ones that are "Waiting" and additionally we have detected a wait chain with other tasks in the list. For the 2 Waiting states, hovering over the cell displays a tooltip which may have more information, like in the following screenshot.

- Location: The Location column displays the method that the task is currently in (i.e. the top most user frame of the task's call stack). Hovering over the cell displays in a tooltip the entire call stack for the task (not the entire call stack for the thread!). Naturally, Scheduled tasks do not have a value in this column.

- Task: The entry point method that was passed to the task when it was constructed. If there was a state argument explicitly passed to the task, the value of that is also shown.

- Thread Assignment: The id of the thread that the task is executing on. Remember, a task can only execute on a single thread, but a thread can be executing multiple tasks. Naturally, Scheduled tasks do not have a value in this column.

- Parent: The Id of the task that is the parent of this task (if there is one). This is not applicable for native scenarios where the concept of parent and child tasks is not a first class citizen in the programming model.

- Task Group: The address of the task_group that scheduled the task. This is not applicable for managed scenarios.

Parent Child View
When the value of any cell in the Parent column is not blank, we know we have parent child relationship(s) in our view. In that case, we can visualize this relationship slightly better by switching to "Parent Child View" via the column context menu (shown in image further above). This switches the first column to contain a treeview that allows collapsing the child nodes/tasks.

Task Context Menu
The ContextMenu described above is the one displayed when right clicking on a column; there is one that is displayed when right clicking on a (task) listviewitem.
- Copy: Copies the cells in view (tab delimited) to the clipboard.
- Select All: Or via Ctrl+A to select all tasks, in order to perform one of the other operations in bulk, e.g. copying.
- Hexadecimal Display: Global debugger setting that switches all debugger windows to hexadecimal display (or Decimal if unchecked).
- Switch To Task: Sets the selected task to be the current task (as discussed above) and hence get the yellow arrow icon. This action is also performed when double clicking on a Task listviewitem.
- Freeze Assigned Thread: The concept of freezing a thread existed before this Visual Studio release via the Threads window. The thread that is frozen does not continue execution when the debugger continues to the next step, until the user Thaws it (via the same menu). From the Parallel Tasks window, freezing affects the underlying thread and all tasks on it. I.e. this is still a thread concept rather than a task concept.
- Freeze All Threads But This: Freezes all threads in view, except the selected one.
- Flag: Same behaviour as clicking on the flag column, described further above.

Call to Action
When you get the VS2010 Beta 1, let me know what you think about this new debugger window as you write your own task-based algorithms: do you like it or do you love it? ;-) More seriously, I am genuinely interested in your bug reports (so the talented developers on my team can fix them for Beta2), what feature do you particularly like (so we make sure not to lose/break it) and what you'd like to see that is not there (so we can include it for the next release or, if it is a low hanging fruit, in this release).

PDB Files

noreply@blogger.com (The Moth) — Wed, 13 May 2009 15:39:00 PDT

I want to share this comprehensive blog article by John Robbins. No need to paraphrase the title, it perfectly describes the content already: PDB Files: What Every Developer Must Know.

Axum

noreply@blogger.com (The Moth) — Sat, 09 May 2009 14:01:00 PDT

My colleagues have released to DevLabs an incubation project: Axum (fka "Maestro").

"Axum aims to validate a safe and productive parallel programming model for .NET"

" Axum is a language that builds upon the architecture of the Web and principles of isolation, actors, and message-passing to increase application safety, responsiveness, scalability, and developer productivity.
Other advanced concepts we are exploring are data flow networks, asynchronous methods, and type annotations for taming side-effects."

After you visit the page and download the bits, head over to the dedicated Axum blog.

Windows 7 Task Manager screenshot

noreply@blogger.com (The Moth) — Mon, 27 Apr 2009 22:59:00 PDT

Previously I linked to a screenshot of 96 virtual processors and now I have access to a machine that tops that!

Count them:

Nothing else to share here, just a geek showing off ;-)

Nice collection of .NET 4 links

noreply@blogger.com (The Moth) — Fri, 24 Apr 2009 17:46:00 PDT

Just came across (and thought I'd share) these resources for .NET 4 and C# 4 features on Bogdan's blog post.

CLR 4 ThreadPool Enhancements

noreply@blogger.com (The Moth) — Thu, 23 Apr 2009 17:22:00 PDT

Eric Eilebrecht (dev on CLR) is kicking off a blog post series on improvements to the CLR 4 ThreadPool. If you've used the .NET ThreadPool, you must read his first installment.

Best source code comments

noreply@blogger.com (The Moth) — Wed, 22 Apr 2009 17:18:00 PDT

Literally laughed out loud when this was forwarded to me and they are way too funny not to share – from stackoverflow:
What is the best comment in source code you have ever encountered?

Measuring performance under Visual Studio

noreply@blogger.com (The Moth) — Mon, 06 Apr 2009 19:58:00 PDT

When I created my Visual Studio C# demos for showing off Tasks versus Threads, I of course created the project in Release mode, but there were 2 additional things that I had to do.

One had little impact, but is important to remember: set the power plan on Windows to "High Performance". Otherwise CPU usage can be throttled by the OS, which is not what you want when you are demonstrating parallelism and 100% CPU usage ;-)

The other had a profound impact and had me puzzled for a bit: use Ctrl+F5 instead of F5. The difference in the time the threads scenario took was humongous. That is because the naïve threads demo creates around 1023 threads and it turns out creating threads under the debugger (F5 case, even in release mode) is measurably slower than not. I should have known that, but I didn't, so sharing it here in case you didn't either: when measuring perf, always use Ctrl+F5 in release mode.

For a lot more on the performance difference between running under the debugger and not, I recommend Joc's blog post: Why is my app so much slower under the debugger.

Internet Explorer 8 using Restart APIs to full potential

noreply@blogger.com (The Moth) — Thu, 19 Mar 2009 12:49:00 PDT

I have been playing with internal bits of Internet Explorer 8 for a while and it is pretty cool. Today the final version has shipped and you can download IE8 from the Microsoft site. To see the many cool enhancements I'd encourage you to watch the short videos (or at least just the Overview) on the dedicated IE8 videos page.

One of the things I like doing to new apps is crashing them. When a windows app crashes, I fully expect it to restart and restore the state it had before it died. I ranted in detail on that front in an older post of mine 2 years ago.

Internet Explorer 8 finally delivers on my request. This is what I see after I crash it and it restarts:

Love it!

Zoom Ctrl + mouse wheel

noreply@blogger.com (The Moth) — Sun, 15 Mar 2009 20:21:00 PDT

Almost all modern UIs support zooming in and out; it is useful for focusing on a specific area (e.g. seeing the detail better) and for managing scale (e.g. seeing the big picture without scrolling).

It has become the standard to offer the zooming function via holding down the Ctrl key and scrolling the mouse wheel. Try it now in your internet browser (IE, firefox etc), in any office application (Word, Excel, PowerPoint) including reading or composing email in Outlook, in windows explorer to see more/less files, in Visual Studio 2010 editor and so on and so forth.

If you take one thing away from this blog post as an end user it is to try Ctrl + mouse wheel. As a developer, offer this feature for your users. I recommend a range of 10% to 2000%.

Beyond the standard keyboard shortcut though, there seems to be no standard for displaying a UI zoom control. Below are some screenshots of zoom controls to prove the point.

Word/Excel/PowerPoint, in the status bar:

IE7, in status bar:

FireFox, hidden in a submenu:

Outlook, hidden in a dialog off a ribbon button:

Windows Photo Gallery:

Class Designer, on a toolbar:

Our team wanted to add a zoom control for a new VS2010 debugger toolwindow. Even within Visual Studio there are various zoom controls. You can see one of them in the screenshots above from the Class Designer (introduced in VS2005). Here is another example introduced in VS2008 for the WPF designer (aka "Cider")

Rather than introduce yet another control that was convenient for us to implement, we decided to follow Cider's example (and also suggested to the UX team to standardize on this for Visual Studio). What I like about this control is that it is quick to use (less mouse travel to get to it than other approaches, and just click and drag instead of combobox clunkiness), I like the way it reports the zoom state at the top e.g. "70%", "x2" and, finally, I love the button at the bottom that toggles between the "fit to screen" and "100%" states. Those of you that used it will have also noticed the aesthetically pleasing fade in/out as you hover on/away from it :-)

Now, even with all these benefits there is a drawback which is acceptable in the WPF designer, but not so acceptable in a smaller surface area (like the typical debugger toolwindow): the control can overlay with the content of the window and, even in the faded out state, it can be annoying for some users. For that reason, we added a toolbar button that simply toggles the visibility of the zoom control. So now you can have your cake and eat it too.

It is amazing to me how smaller obvious features such as adding zoom support, take more time to think over than what one might expect… If you have used zooming in an application that you believe is better than what's described above, please share!

Perspective on Program Manager

noreply@blogger.com (The Moth) — Tue, 10 Mar 2009 12:21:00 PDT

Apologies if you were expecting me to share my own insights (beyond what I already did last year).

Instead I encourage you to read Joel's take (slightly biased towards junior PMs, towards consumer product PM and towards the early stages of the project lifecycle).

Around 1500 geeks in Seattle for the MVP Summit 2009

noreply@blogger.com (The Moth) — Fri, 27 Feb 2009 15:39:00 PST

My last participation as an attendee was the MVP summit in 2005 and 4 years later I'll be participating again but this time from the other side (was planning to do it in 2007 but failed). There are many events to go to and I've narrowed it down to the following. If you read this blog and you are around, why not find me and buy me a beer? ;-)

Saturday – ALT.NET Seattle 2009.

Sunday – WSCTC 4th floor (welcome, keynote, reception), and then
Sunday – Jillian's for evening geek party.

Monday – Hanging out with Device MVPs: Lunch time + an evening reception, on Redmond campus.

Tuesday – presenting to C++ MVPs about parallel debugger, and then
Tuesday – presenting to Managed Languages MVPs about parallel debugger, and then
Tuesday – evening at the MVP Summit party.

Wednesday – probably at WSCTC (keynote, panel and general sessions + lunch).

Parallelism in Greek

noreply@blogger.com (The Moth) — Mon, 23 Feb 2009 16:53:00 PST

During my working_from_Greece stint over the Christmas and New Year's period, I squeezed in presenting at an event in Athens. Parts of the recorded presentation are now available on the Greek MSDN pages. Scroll down the page to choose between the 2 presentations

The 1st presentation was this one. The 2nd presentation was a (interactive) Greek version of the code-heavy Parallel Programming session.

Finally, for those of you physically living in Greece, there is a 2-page article/interview on parallel computing in February's PC Magazine.

Why Care About Parallelism aka The Inevitable Shift

noreply@blogger.com (The Moth) — Sun, 15 Feb 2009 21:56:00 PST

That was the title of a 45-minute (inc. questions) presentation I gave last December. It was a basic introduction to the manycore shift including what is parallelism and why software developers should care. The session ended by touching at a very high level on what Microsoft is doing in this space.

It was slides only (well, there were 3 demo/sample apps shown but no code) and you can download the deck in a ZIP file (the slides are a montage from many other decks of other Microsoft employees).

The basic flow has as follows
slide 3: Understanding Moore's Law
slide 4-7: Moore's law is still alive, but is not translated to higher frequencies. That is mainly due to the power wall, which at the end of the day means more heat than the CPU manufacturers can deal with
slide 8: So instead the manycore shift enters with CPU manufacturers adding more cores to the die rather than making a single one go faster. Predictions are for 100-core machines within 5 years (for the record, these are not my predictions)
slide 9: For us software developers, to take advantage of the increased total horsepower of manycore machines (on the client/desktop) you must employ parallelism. No other magic bullet or automatic gain. It is naïve to think that we will not need the increased speed or that we don’t know what to do with it:
a. We have been taking advantage (implicitly or explicitly) of increased CPU speeds over our entire existence. Why do we think we'll stop now?
b. Every shift in the software industry (whether it is the move from console to GUI apps, or desktop to mobile apps or even the recent client side web programming advancements) has been partly possible due to being able to take advantage of higher processor speeds. Why will the next shift in computing (whatever that is) be different?
slide 10: DEMO the morphing application (same one I showed at Tech Ed EMEA)
slide 11: Important to note that not all of the additional cores will be as fast as today's CPUs – they will more likely be of lower frequency; so to get even the same output that we get from one core today, we'll have to use parallelism to leverage more than one cores.
slide 12: Also important to note that it isn’t just Microsoft telling this story. Virtually every industry player is predicting the same situation.
slide 13: So the question is: what do I do with all those cores? Besides the same goals that good multithreading has (responsiveness, scalability and latency-awareness) parallelism takes it to the next level.
slide 14 to 15: Obey Amdahl's Law: do the same thing, but genuinely faster
slide 16: Obey Gustafson's law: do more stuff in the same time!
slide 17: Use speculative execution.
slide 18: DEMO the RayTracer application (same one I showed at PDC)
slide 19: "OK, I am sold. I must use parallelism. Show me how"… "Well, actually it is darn hard today if you try and use traditional multithreading to achieve parallelism"
slide 20: Microsoft established the Parallel Computing Initiative to address the goals/symptoms above
slide 21: Not the only team in Microsoft thinking about this problem. Attacking it from many angles.
slide 22: DEMO Baby Names application
slide 23: I bet you want to see some code… Read the Summary slide, and let's move on to the next session.

Give a session on Parallel Programming (or just learn from it)

noreply@blogger.com (The Moth) — Thu, 05 Feb 2009 14:15:00 PST

Last year gave the same session on Parallel Programming twice: at PDC2008 and Tech Ed EMEA 2008 (identical content). The fact that those sessions ended up on the #3 and #2 spots in the ranking order, speaks to the fact that people are really interested and accepting of this topic. It is also testament that the technology Microsoft is releasing with Visual Studio 2010 is very compelling. So I invite you here to take my content and reuse it in your local regions!

The recordings (and slides) of the two identical sessions are available so you can learn by watching them: links from here and here.

I have also captured the session content on this blog:

1. Briefly introduce the manycore shift and clarify the release vehicle for Parallel Extensions.
2. Run one of the samples that ship with Parallel Extensions to demonstrate the end user benefit (no code shown at this point).
3. Clarify the potential difference between parallelism and multi-threading.
4. DEMOnstrate Fine Grained Parallelism via the Task-based Programming model built on the new ThreadPool.
5. DEMOnstrate Debugging Parallel Applications.
6. DEMOnstrate Structured Parallelism via the static Parallel class, e.g. Imperative Data Parallelism.
7. DEMOnstrate Declarative Data Parallelism: PLINQ.

Many conferences/user groups are interested in technical sessions on Parallel Programming in .NET 4.0 and Visual Studio 2010 so use the links above to learn and share.