Barney's Rubble
Multi-Core Morass
Servers are keeping pace, but clients are another story.
Criticism should be carefully measured, so I'll dole a half portion of praise and an equal share of regret. Let's start with praise. On the server side I firmly believe Microsoft has done a fine job. Linux is great, and free if you don't need support. But for shops with a Windows infrastructure, Windows servers are more easily managed, and run native apps like Exchange and SQL Server like nobody's beeswax. And the third-party market is unmatched.
From a purely technical point of view, Windows -- and Linux/Unix -- servers do a good job supporting high-end apps and taking advantage of powerful hardware such as multi-core, multiprocessing and clustered systems. A good part of that is because server apps tend to be multithreaded. There's your cup half full.
Now let's look at the empty half -- the client side. Windows Vista was in the works for about half a decade. In fact, Microsoft threw out all the source code and started from scratch in 2004. And in 2004, the multi-core writing wasn't just on the wall -- it was all over the dang building. For some reason, Microsoft forged ahead as if the single processor would go on forever.
Exploiting multi-core is not a simple concept. All elements are to some degree involved and carry some responsibility. Apps can be written in threads, the OS can schedule tasks across cores or middleware can do a lot of the heavy lifting.
I've been researching this area for months, and the issues are still murky. What is clear is that Vista and XP take a decent amount of advantage of a couple of cores, and performance increases degrade steeply as you add more. Also, Microsoft hasn't done enough to optimize the desktop for multi-core, such as discovering large apps and allocating them to specific cores. Hopefully Windows 7, due in a year or three, will be smarter about high-end hardware. Meanwhile the Linux and Mac camps crow about native OS multi-core support. Apple, for instance, has an eight-core desktop and brags that its scheduler makes all cores usable.
Microsoft is also just getting started on building tools for parallel programming. But it's getting on the move to some extent.
Here's a rundown of recent activity: While Microsoft Research works on parallel tools that are pretty far out, Redmond's developer division just announced ParallelFX, a set of libraries and extensions to the .NET Framework 3.5. Related to this is a new functional language designed for microprocessing called F#. However, this is nowhere near the general-purpose language that C and its various flavors are.
As for data-intensive apps, Microsoft has Parallel Language Integrated Query, a tool that lets queries operate across multiple cores. All these answers require good old-fashioned programming.
Last, Microsoft promises that Windows 7 will be far more multi-core-ready than what we have today.
What am I missing? Help me straighten this mess out by writing me at [email protected].
About the Author
Doug Barney is editor in chief of Redmond magazine and the VP, editorial director of Redmond Media Group.