Monday, July 28, 2008
When most people's brains first light up on why parallelism is the next BigThing, some jump to the conclusion that Moore's law is over. Let's clear that up below.
All of you know Gordon Moore's law which boils down to the prediction of
So, now that chip manufacturers cannot make single CPUs any faster (well, they can, but they can't cool them down enough to make them useful), they are resorting to having chips with multiple cores, which we are terming the manycore shift. The manycore shift has a profound impact on developers (especially those programming for the desktop client) in that their software now has to learn how to take advantage of parallelism.
So if you followed the logical flow so far, you'll conclude that Moore's law is still alive: we are still getting more silicon, but it does not translate to increased linear speed, but rather to parallel "engines" that your software must learn to utilise.
I am glad we cleared that up :)
All of you know Gordon Moore's law which boils down to the prediction of
"the number of transistors on a chip will double about every two years"In the last 30-40 years the previous prediction has manifested itself in clock speed increases and that is what has tricked most of us to associate Moore's law with CPU speed.
So, now that chip manufacturers cannot make single CPUs any faster (well, they can, but they can't cool them down enough to make them useful), they are resorting to having chips with multiple cores, which we are terming the manycore shift. The manycore shift has a profound impact on developers (especially those programming for the desktop client) in that their software now has to learn how to take advantage of parallelism.
So if you followed the logical flow so far, you'll conclude that Moore's law is still alive: we are still getting more silicon, but it does not translate to increased linear speed, but rather to parallel "engines" that your software must learn to utilise.
I am glad we cleared that up :)
Labels: ParallelComputing
Tuesday, July 22, 2008
One of my pet peeves is ensuring that whenever there is code that explicitly creates a thread, to always have an accompanying statement that names the thread. This is invaluable in debugging. With managed code, it is so simple, just one extra statement to set the thread's Name property (which you can only do once at runtime, of course).
This is such a useful thing to have when debugging, that in VS2008 the ability was added to name threads after execution had started. The idea there is for naming Threads that you don't control but still need to easily identify for debugging purposes. The name does not persist cross debugging sessions and indeed it is not used at runtime by anything other than your... eyes. I describe this feature as part of my video on all the new VS2008 threading enhancements (watch minutes 06:00 through 08:20, although I recommend the full 15 minutes).
At the OS level the ability to have names against threads is not supported (but you can use nice HEX ids to assist with your debugging ;)). Recently I discovered that there is an old trick (or hack IMO) that you can use with certain tools (inc. Visual Studio) to set names on native threads too. To get the details visit this short How To on MSDN. I did a quick search and discovered two more places on the web where this is described. One is on codeproject which is blatantly lifted from MSDN but it adds a couple of screenshots. The other also points to (an obsolete place on) MSDN and adds a bit more detail.
In short, for my managed friends: Search your code base now for the string "= new Thread" and for every match that you find, verify that you are also setting the Name property. You'll thank me later.
This is such a useful thing to have when debugging, that in VS2008 the ability was added to name threads after execution had started. The idea there is for naming Threads that you don't control but still need to easily identify for debugging purposes. The name does not persist cross debugging sessions and indeed it is not used at runtime by anything other than your... eyes. I describe this feature as part of my video on all the new VS2008 threading enhancements (watch minutes 06:00 through 08:20, although I recommend the full 15 minutes).
At the OS level the ability to have names against threads is not supported (but you can use nice HEX ids to assist with your debugging ;)). Recently I discovered that there is an old trick (or hack IMO) that you can use with certain tools (inc. Visual Studio) to set names on native threads too. To get the details visit this short How To on MSDN. I did a quick search and discovered two more places on the web where this is described. One is on codeproject which is blatantly lifted from MSDN but it adds a couple of screenshots. The other also points to (an obsolete place on) MSDN and adds a bit more detail.
In short, for my managed friends: Search your code base now for the string "= new Thread" and for every match that you find, verify that you are also setting the Name property. You'll thank me later.
Labels: ParallelComputing
Saturday, July 12, 2008
Yesterday a new 1-hour video interview on C# 4.0 was posted on channel9.
At some point the question is posed to Anders:
At some point the question is posed to Anders:
"What are some of the big issues that you are thinking about for the future?"and Anders' reply (ffw to 39:56) identifies concurrency as the #1 thing:
"Concurrency is by far... profoundly changing... Moore's law... we've been ignoring concurrency because we could... now we can't... it is a damn hard problem..."My favorite quote comes at 45:13 and includes hand gestures too:
"It is foolish to think that somehow we are going to be able to pepper concurrency on your code and you wouldn't need to modify anything in your apps today for them to run concurrently"For the stuff in-between and to get the complete picture, watch the video.
Labels: ParallelComputing
Monday, June 02, 2008
Following the first ever drop last December, the latest preview is now available. Ed has the link and details here.
Labels: Links, ParallelComputing
Friday, May 23, 2008
- Here are the slides (save as pptx).
- The demos were a subset of these videos: Samples, Task etc, Parallel class, PLINQ.
Thank you to those that attended my Parallel Extensions session earlier today at DevDays. I don't think I have ever seen so much interest in a technology before (I was answering questions for a good 20' after my 70' session ended). This is turning out to be one of my favourite talks – it just gives itself ;-)
- The demos were a subset of these videos: Samples, Task etc, Parallel class, PLINQ.
Thank you to those that attended my Parallel Extensions session earlier today at DevDays. I don't think I have ever seen so much interest in a technology before (I was answering questions for a good 20' after my 70' session ended). This is turning out to be one of my favourite talks – it just gives itself ;-)
Labels: Events, ParallelComputing
Friday, February 29, 2008
A while back I recorded some screencasts on this hot topic, and I see now that the popular VSJ developer magazine has published my article on Parallel Extensions to the .NET Framework.
For those of you that can't get a hard/physical copy, they have kindly made it available online for your reading pleasure.
For those of you that can't get a hard/physical copy, they have kindly made it available online for your reading pleasure.
Labels: dot NET general, ParallelComputing
Friday, November 30, 2007
The Parallel Extensions to .NET Framework 3.5 is available! Download and play with the first ever public drop - the December CTP.
If you are then ready to dig into it, I have three 20' screencasts (plus more cooking):
1. Tour of the Samples. A tour of what gets installed to get you started.
2. Declarative data parallelism. This is about PLINQ.
3. Imperative data parallelism. This is about the static Parallel class.
After watching the above, visit the relevant MSDN dev centre. For any questions please use the dedicated online forums. For feedback please use the connect site. If you want to congratulate or blame the product team, visit their blog.
If you are then ready to dig into it, I have three 20' screencasts (plus more cooking):
1. Tour of the Samples. A tour of what gets installed to get you started.
2. Declarative data parallelism. This is about PLINQ.
3. Imperative data parallelism. This is about the static Parallel class.
After watching the above, visit the relevant MSDN dev centre. For any questions please use the dedicated online forums. For feedback please use the connect site. If you want to congratulate or blame the product team, visit their blog.
Labels: dot NET general, ParallelComputing
# posted by The Moth @ 09:17 
Thursday, November 29, 2007
"Parallel Computing Initiative Ushers Computing into the Next Era"
A bit high level (marketing?) at times in this 10-page document, but there is definitely some interesting stuff in there - read it!
A bit high level (marketing?) at times in this 10-page document, but there is definitely some interesting stuff in there - read it!
Labels: Links, ParallelComputing
# posted by The Moth @ 01:17
Wednesday, November 28, 2007
I am a bit slow so I had to read this page twice on wikipedia, but it was worth it in the end, I think. See if you get it all in one pass: Futures and Promises. Because my imperative head wasn't completely blown away I also spent time trying to grok dataflow programming. Opens your mind doesn't it?
Labels: Links, ParallelComputing
# posted by The Moth @ 16:25
Via Jason, I discovered this post on the concurrency learning curve and following links from there, I found Intel's view on "data and task parallelism". Interesting stuff!
Labels: Links, ParallelComputing
# posted by The Moth @ 09:50
Tuesday, September 25, 2007
Rather than writing or screenshoting the new multithreaded debugging enhancements in Visual Studio 2008, I thought I'd create a 15' video to demonstrate them. See if you can spot what the bug is before I "discover" it in my demo ;-).
Labels: Orcas, ParallelComputing
# posted by The Moth @ 05:51
Friday, September 21, 2007
Angelos found an interesting article via the UK MSDN Flash. If you did as well, check out more about that on the author's blog (one more reason to be sorry PDC was cancelled).
Anyway...
In a not so unrelated area, on a list that I am a member of, a question came up about affinitising a managed thread to a specific CPU. Jeffrey Richter came to the rescue by pointing out the
The code (and much more) is part the Power Threading Library which is available on the Wintellect site.
Anyway...
In a not so unrelated area, on a list that I am a member of, a question came up about affinitising a managed thread to a specific CPU. Jeffrey Richter came to the rescue by pointing out the
System.Diagnostics.ProcessThread and its ProcessorAffinity property but then the harder question came along of how to associate that class with the System.Threading.Thread class. Below is the answer in C# from Mr Richter again: // Call this passing in 0...where
public static ProcessThread GetProcessThreadFromWin32ThreadId(Int32 threadId) {
if (threadId == 0) threadId = ThreadUtility.GetCurrentWin32ThreadId();
foreach (Process process in Process.GetProcesses()) {
foreach (ProcessThread processThread in process.Threads) {
if (processThread.Id == threadId) return processThread;
}
}
throw new InvalidOperationException("No thread matching specified thread Id was found.");
}
ThreadUtility is a class containing at least: [DllImport("Kernel32", EntryPoint = "GetCurrentThreadId", ExactSpelling = true)]
public static extern Int32 GetCurrentWin32ThreadId();The code (and much more) is part the Power Threading Library which is available on the Wintellect site.
Labels: dot NET general, ParallelComputing
# posted by The Moth @ 09:27
Monday, July 09, 2007
Having done a lot of real world work with threading in the .NET Framework including working with the numerous limitations of NETCF v1.0 (inc. implementing the BackgroundWorker for it), I read with interest Sam's parallel computing blog post to see what links there would be in there and I wasn't disappointed. Check it out if you are new to threading in the managed world. That reminded me about a related topic that I keep mentioning at the end of my LINQ presentations and that I've been meaning to blog about in response to Tim's question: Parallel LINQ (PLINQ).
One of the numerous benefits of LINQ is the move to declarative programming, which has side benefits over and beyond the obvious ones. By writing code that tells the engine what it is that we want it to do rather than how to go about it, we open new possibilities where the engine can take our intent and split/execute it on multiple threads/cores (since ultimately it is responsible on the how). While most devs "get" that, it may sound a bit woolly to others, so here are some links/info about PLINQ.
I believe the first mention of PLINQ is in this eWeek article (August 2006). Joe Duffy announced his involvement (September 2006) and then followed it up with more info and a slide deck (January 2007). Bart watched a presentation on the topic and spills the beans on the AsParallel extension method which he follows with a NON-Plinq code example (April 2007). Finally, watch a real 5' demo by Luca from Tech Ed [between 51:26-56:40] (May 2007).
Of course, it is early days and PLINQ will not ship with VS2008 (or even as part of the wider Orcas-wave) but you get the idea... The earlier you start taking advantage of LINQ, the earlier you'll be able to take advantage of PLINQ when it eventually ships ;)
One of the numerous benefits of LINQ is the move to declarative programming, which has side benefits over and beyond the obvious ones. By writing code that tells the engine what it is that we want it to do rather than how to go about it, we open new possibilities where the engine can take our intent and split/execute it on multiple threads/cores (since ultimately it is responsible on the how). While most devs "get" that, it may sound a bit woolly to others, so here are some links/info about PLINQ.
I believe the first mention of PLINQ is in this eWeek article (August 2006). Joe Duffy announced his involvement (September 2006) and then followed it up with more info and a slide deck (January 2007). Bart watched a presentation on the topic and spills the beans on the AsParallel extension method which he follows with a NON-Plinq code example (April 2007). Finally, watch a real 5' demo by Luca from Tech Ed [between 51:26-56:40] (May 2007).
Of course, it is early days and PLINQ will not ship with VS2008 (or even as part of the wider Orcas-wave) but you get the idea... The earlier you start taking advantage of LINQ, the earlier you'll be able to take advantage of PLINQ when it eventually ships ;)
Labels: Links, LINQ, ParallelComputing
# posted by The Moth @ 09:43
Copyright © Daniel Moth
