Parallel Tools and Visual Studio, or Steve's Going to Paris, Why Not Me?
For not ever having the opportunity to speak to Microsoft's Steve Tiexeria prior to this week, I've been lucky enough to have a double (or triple) dose of him.
Our first conversation took place upon my receiving an excellent article he wrote about the parallel programming features in Visual Studio 2010 (which Dr. Dobb's will publish next week). Then it was the opportunity to be a fly on the wall and listen to a conversation between Steve and Intel's James Reinders, which I mentioned here.
Today I was fortunate enough to attend a presentation Steve made at the parallel programming conference I'm attending, where he discussed (you guessed it) the steps Microsoft is taking to help move parallelism into the mainstream. Steve's particular interest is with developer's tools, which is no surprise considering that he's a member of the team that builds the parallel tools inside VS 2010.
Why is Microsoft so keen on parallelism? Because, as Steve said, multicore is the new normal, and multicore makes parallelism attractive and possible. A key component of Microsoft's push to parallel involves the Concurrency Runtime (CRT) framework for C++. The CRT is designed to simplify parallel programming by raising the level of abstraction so that you do not have to manage the infrastructure details that are related to concurrency. The CRT has three features which stand out:
- It is programming-model independent.
- It has a scheduler that:
- Supports low-overhead scheduling and load balancing
- Is policy driven
- Supports multiple scheduler instances, cooperative blocking, and supports UMS on Windows 7
- Provides several APIs (Scheduler, SchedulerPolicy, ScheduleGroup, Context)
- Ithas a Resource Manager that:
- Serves requests for physical processors, intraprocess
- Supports dynamic load balancing between scheduler instances
- Supports multiple interfaces (Ischeduler, IVirtualProcessorRoot, IThreadProxy, IExecutionContext)
CRT sits atop of the operating system and executes tasks by maximizing utilization of available cores using techniques such work-stealing (among others) to efficiently distribute work among resources. The CRT provides a default scheduler so that you do not have to manage the details.
Clearly there's much more to the CRT than I can describe here. But one thing I can tell you is that it is an important feature and something you need to get up to speed on if you're going to be parallel programming on Microsoft platforms. You can find Microsoft's official introductory discussion here.
One thing that underscores this for me is Intel's take on the CRT. They see it as a good thing to enable parallelism, even to the extent of sharing CRT-related source code and information with Microsoft.
As for me, I'm trying to figure out how I explain to my boss that I need to hear Steve's take on CRT and Visual Studio 2010 one more time. That Steve let it slip his next stop is Paris has nothing to do with it.