RDN Directions
Parallel Lines Meeting
With Parallel Extensions, Microsoft is starting to give developers tools to build applications that can take advantage of the multi-core world.
With a set of extensions to the .NET Framework 3.5, Microsoft is beginning to come to terms with a sea change in the world of microprocessors that threatens to undermine a cycle that Microsoft has long relied on: that faster processors would always arrive to handle ever-more capable software.
Last March, I described the change in hardware:
"Once upon a time, in the not-too-distant past, developers could count on the fact that any program they wrote today would run faster tomorrow, thanks to faster AMD processors. But starting in 2006, both Intel and AMD moved from making their chips faster by pumping up the clock speed, to making them faster by building more processor cores into the same package."
In effect, a rising tide (CPU clock speeds) no longer lifts all boats (applications). But with the Parallel Extensions, Microsoft is starting to give developers tools to build applications that can take advantage of the multi-core world.
Moore's Law
Not Repealed
For nearly four decades, Moore's Law, which states that the number of transistors that can be placed on an integrated circuit -- such as a microprocessor -- doubles roughly every two years, has manifested itself through faster and faster clock speeds: up by a factor of nearly 1,000 from the 4.77MHz of the original IBM PC to the multi-gigahertz wonders of today.
But the ability of engineers to design denser processors has outstripped their ability to cool those processors. Today, many high-performance laptop computers don't deserve their name because they're literally too hot to rest on your lap. Engineers at Intel and AMD responded with characteristic cleverness. If more transistors can't be used to make each processor faster, why not use them to cram more processors into each computer?
It's a great idea, but the approach shifts the burden of translating Moore's Law into a benefit to the end user from the hardware engineer to the application developer. The rising tide of clock speeds no longer boosts all applications: Only those applications able to divide their work into parallel units will fully benefit from the new world of multi-core systems.
I say fully because end users can see immediate benefit with unoptimized programs running on dual-core processor systems. The second core can be used to handle the increasingly heavy burden of security software, such as anti-virus, firewall and malware prevention, while the first core simultaneously powers the foreground application. But that benefit doesn't scale up to the four-core and eight-core processors coming very soon from Intel and AMD.
Plumbing PLINQ
The problem is, creating
parallel -- or concurrent -- applications is hard. With the Parallel Extensions to .NET Framework 3.5, Microsoft is taking the first step toward helping developers with this task. In particular, corporate developers who are most likely to be using the .NET Framework will benefit.
The Parallel Extensions build on Language Integrated Query (LINQ). LINQ is a feature introduced in the .NET Framework 3.5 that allows developers to write SQL-style queries in Visual Basic and C# and have those queries operate on data in SQL Server (LINQ to SQL), in XML format (LINQ to XML) or in traditional data structures such as lists and arrays (LINQ to Objects). The Parallel Extensions include a new version of LINQ to Objects known as Parallel LINQ (PLINQ).
With PLINQ, developers can examine their code and identify places where they're using LINQ to query their internal data and, with a very small change to the code, enable the various phases of those queries to run in parallel on multi-core systems.
Similarly, new parallel versions of the traditional "for" and "foreach" operations allow developers to find places in their applications that walk through data and enable them for parallel operation.
But just because the new extensions allow code to run in parallel doesn't mean the code is safe to run in parallel. Bugs can appear and disappear depending upon how many processors the system has and what other tasks are running -- and debugging is a nightmare.
As Herb Sutter, chair of the ISO C++ committee and software architect at Microsoft, noted: "The vast majority of programmers today don't grok concurrency, just as the vast majority of programmers 15 years ago didn't yet grok objects."
In addition, this news may be great for .NET developers, but there are a lot of C++ developers out there -- particularly among commercial ISVs -- and it does nothing for them. But Microsoft is aware that the need for more software parallelism extends beyond the .NET Framework and has staffed teams in Microsoft Research and the Developer Tools division to work on it.
But even with those concerns, the Parallel Extensions are an important step. They point the way to how Microsoft will try to take a very important set of its developer customers into the future of parallel programming.
About the Author
Greg DeMichillie analyzes and writes about Microsoft's development platform and tools for Directions on Microsoft, a research firm dedicated to tracking Microsoft. He was previously the group program manager at Microsoft responsible for the overall design and feature set for Visual C# and C++. A founding member of the C# language team, DeMichillie was a key contributor to the initial design and development of .NET.