They say you can never be too young, or too rich. Or too handsome or too beautiful. And in the case of Intel-architecture PCs, it also seems that you can never have too many cores. With both the industry leader and its archrival, AMD, ratcheting up the core count, the future of personal computing will be experienced in parallel -- parallel processing, that is. The days of cranking up the clock speed to keep the pipeline flowing are gone. These days, it's all about width: How many instructions can you execute per clock cycle simultaneously?
Going hand in hand with the multicore push has been the evolution of desktop Windows to support these new chips. Today's dominant flavors -- Windows XP, Windows Vista, and soon Windows 7 -- all support Symmetrical Multiprocessing (SMP) out of the box, a trait they inherited thanks to their Windows NT (New Technology) lineage. However, experience has shown that multiprocessing across discrete CPUs is not the same thing as multiprocessing across integrated cores within the same CPU.
[ Is it Windows 7, or Windows Vista R2? See "Windows 7 unmasked." Read the great Windows 7 debate. Is Windows 7 necessary? See "Death match: Windows Vista versus XP." Monitor the performance of your Windows systems with Windows Sentinel. ]
As a result, current-generation software products incorporate additional optimizations to allow them to perform at their best in the low-latency, shared-cache world of multicore. This includes Windows Vista, which shipped at the beginning of the multicore transition, and Windows 7, of course, but not Windows XP. All of which begs the question: How much of an impact does this additional multicore tuning have on real-world OS performance and scalability? And what, if anything, do you gain or lose by sticking with Windows XP versus migrating to one of Microsoft's more modern versions?
In order to test the limits of Windows multicore support, I constructed a comprehensive, multiprocess workload test package using the ADO (database), MAPI (workflow), and WMP (media playback) Stress objects from the DMS Clarity Studio; see "How I tested" for the details. I then executed the package across representative dual- and quad-core systems in an effort to document the scalability, the execution efficiency, and the raw performance of the workloads when running against each of the available Windows incarnations.
What I found may surprise you. Not only does Microsoft have a firm grasp of multicore tuning, but its scalability story promises to keep getting better with time. In other words, Windows Vista and Windows 7 are poised to reap ever greater performance benefits as Intel and AMD extend the number of cores in future editions of their processors.
Windows XP SP2
Windows XP is the OS that simply will not die, and for good reason: It's mature, stable, and - - most important -- fast as the wind on today's hardware. In fact, Windows XP outpaced its younger siblings by a factor of two during multiprocess workload testing -- concurrent database, workflow, and multimedia tasks on our dual-core test bed and by up to 66 percent on our quad-core test bed. (See summarized test results on Lab Notes.)
In terms of raw application throughput, Windows XP clearly is still king of the hill. However, despite its current edge on dual-core and quad-core systems, Microsoft's 8-year-old OS is beginning to show its age. For example, when you contrast the dual- and quad-core transaction times for the ADO (database) and MAPI (workflow) workloads, you see that scalability -- in terms of a percentage improvement from dual-core to quad-core -- is capped at 265 percent for the database tasks and 32 percent for the messaging workflow tasks. While excellent by legacy Windows NT standards, these improvements pale next to the 571 percent boost witnessed for the same SQL-driven database workload under Windows 7, or the 58 percent improvement for the MAPI message store workflow task under Windows Vista.
My interpretation: Windows XP's aging kernel, though SMP-aware, has never been fully optimized for multicore computing. By contrast, both Windows Vista and Windows 7 have benefited from years of tuning and tweaking (including the removal of various global SMP locking mechanisms) to allow them to better exploit all those additional CPU cores. This scalability advantage doesn't erase XP's performance edge on today's dual- and quad-core systems; even on tomorrow's eight-core CPUs, XP should remain unchallenged. But it does set the stage for an eventual inflection point where, given a sufficient number of cores, Windows Vista and Windows 7 will close the performance gap with XP.
Meanwhile, XP will continue to lay claim to the title of the leanest 64-bit NT kernel-based Windows platform (sorry, Windows 2000, you're 32-bit only), which is evidenced by its superior execution efficiency. If you take the raw transaction times for the database and workflow tasks, then factor them against the average processor utilization for these same workloads, you see that Windows XP consumes roughly 7.2 and 40.7 billion CPU cycles, respectively, to complete a single pass of the database and messaging workflow transaction loops on our quad-core test bed. By contrast, Windows Vista takes 10.4 and 51.6 billion cycles for each workload, while Windows 7 consumes 10.9 and 48.4 billion cycles. Translation: On quad-core, the newer operating systems are at least 40 percent less efficient than XP in the database tasks and roughly 20 percent less efficient in the workflow tasks.
In the end, it all comes down to the complexity of the execution path. With its simpler legacy kernel devoid of DRM hooks and other performance-sapping baggage, Windows XP provides a cleaner code path for the workloads to navigate as they execute. This, in turn, translates into better overall performance with lower consumption of CPU cycles. The flip side is that these performance advantages are likely limited to the current generation of quad-core systems, and perhaps tomorrow's eight-core CPUs, and may quickly evaporate as new system designers seek to incorporate increasing degrees of parallelism into their products.
Windows Vista SP1
Windows Vista is the OS that everyone loves to hate. But like those '70s gas-guzzling cars and '80s hair bands, history will eventually record that Vista was an important turning point in Windows development, a bitter pill that had to be swallowed in order to move the platform forward.
And what a horse pill it was! Vista introduced a kind of memory-sucking, CPU-swamping, disk-thrashing hyperactivity that was entirely foreign to its intended audience of XP users. And regardless of how well-intentioned the designers were -- doing extra stuff in the background to help you work better seems like a great idea on the surface -- the net result was a sluggish OS that made a terrible first impression.
Fortunately for Microsoft, Vista had Moore's Law on its side. The combination of increased CPU power -- including the move to multiple cores -- and cheap memory and storage have helped offset Vista's perceived "bloat" to a point that, for many users, the OS is now quite usable, at least on modern hardware. All of which bodes well for Vista's successor, Windows 7, which performs quite similarly to its progenitor.
But first, the straight skinny on Vista: Compared with Windows XP, Vista delivered database transaction times that were a full 92 percent slower on our dual-core test bed. However, when the focus shifted to our quad-core system, the performance gap with XP narrowed to just 19 percent. Likewise, the workflow portion of the test went from a 98 percent delta on two cores to a more modest (yet still gaping) 66 percent delta on four.
There are two key takeaways from the above data points. First, the workloads still run much slower on Vista than on XP. This is true for both dual- and quad-core systems. Second, Vista scales better than XP when moving from two to four CPU cores. This is demonstrated by the way that Vista closes the performance gap with XP as you increase the core count. Taken to its logical conclusion -- and disregarding for the moment external factors, like bus speeds, I/O contention, and memory latency -- Vista would ultimately overtake XP when the core count reaches between 32 and 64.
With quad-core systems now rapidly sizing up as the norm, and with six- and eight-core parts likely to become commonplace within the year, it seems clear that the multicore kernel tweaks Microsoft made to Vista will eventually pay dividends as its superior scalability becomes more of a factor. But for now, with today's hardware, Vista's inherent complexity means that our workloads have to navigate a much longer and more convoluted code path, all of which shows up in both the raw transaction times and in the underlying execution efficiency.
For example, when viewed under the same processor-utilization parameters as Windows XP, Windows Vista consumes 40 percent more CPU cycles per database transaction on our dual-core test bed and 44 percent more on our quad-core test bed. Similarly, Vista chews up 30 percent more cycles when executing our workflow transaction loop on dual-core and 27 percent more cycles on quad-core.
You can chalk this overhead up to several factors: changes to the MDAC or MAPI code stacks; increased code path complexity in the kernel (DRM rears its ugly head); or interference from additional background processes. But the bottom line is that the CPU has to chew through more code each time it executes one of the workload transaction loops, and this translates into poorer overall performance as the CPU tries to juggle the workloads against all of the other processes that are competing with them for processing time. And that's why Vista is so much slower than XP at a great many tasks.
Windows 7 beta
Windows 7 seems to be many things to many different people. To the enthusiast crowd, it's the cool new OS of the moment, the one that will fix all of Vista's ills and make the world right again. To desperate IT planners, it's a potential "third way" out of their current XP-versus-Vista predicament. But for the rest of us (that is, veteran Windows users who can see through the hype), Windows 7 is really just Windows Vista with some performance tweaks and an updated Explorer shell. It's a modest update that may or may not swing the public-perception pendulum back in Microsoft's favor.
It should come as no surprise that Windows 7 performs very much like its predecessor. In fact, during extensive multiprocess benchmark testing, Windows 7 essentially mirrored Vista in almost every scenario. Database tasks? Roughly 118 percent slower than XP on dual-core (Vista was 92 percent slower) and 19 percent slower than XP on quad-core (identical to Vista). Workflow? A respectable 38 percent slower than XP on dual-core (Vista was 98 percent slower) and 59 percent slower on quad-core (Vista was 66 percent slower).
Windows 7 also scales similarly to Vista when moving from dual- to quad-core. Our database workload showed a whopping 571 percent improvement with the addition of two more cores (Vista showed a 492 percent gain), while our workflow workload experienced a less compelling 15 percent speed-up (Vista gained 58 percent on this test). This latter discrepancy may have more to do with limitations in the MAPI subsystem's scalability (Windows 7 was already 44 percent faster than Vista on dual-core for this particular workload) than any real limitation in Windows 7.
Regardless of how you slice the numbers, Windows 7 and Vista remain birds of a feather and clearly a very different species of animal from Windows XP. You can see this divergence in the overall execution path complexity for Windows 7. Like Vista, this new Windows chews up a lot more CPU cycles per transaction loop than XP -- from 39 to 68 percent more on dual-core and from 19 to 51 percent more on quad-core (the lower figures in each case representing the workflow workload, and the higher figures the database workload). Any illusions about Windows 7 somehow being leaner or more efficient than Vista can now be thrown out the window, right along with the infamous "new kernel" myth and related rumors and misconceptions.
But it's not all bad news with Windows 7. Microsoft's new OS has a clear multicore scalability advantage over both Windows XP and Windows Vista, especially on less I/O-bound tasks like our multiprocess database workload. (We can thank SQL Server 2008 for that one.) In fact, with its second-generation multicore tweaking (good-bye, global lock!), Windows 7 is poised to overtake XP even earlier than Windows Vista -- perhaps at 16 or 24 cores. In the meantime, you certainly won't lose anything by moving from Vista to Windows 7, and you may even gain a few seconds here and there, thanks to its better kernel tuning.
The once and future kernel
Microsoft has been saying for a while now that the Vista kernel has been optimized for multicore computing. Now, with Windows 7, the company's technical evangelists are proudly pointing to the elimination of certain global SMP-locking mechanisms in the updated kernel. However, as Microsoft insiders such as Mark Russinovich are quick to point out, the benefits of these changes won't be felt until core counts climb well beyond today's dual-core and quad-core implementations.
My own testing would seem to corroborate Microsoft's story. If anything, the company is underselling its multicore advantage. Clearly, the optimizations made to the Vista kernel -- both in its original incarnation and in its updated Windows 7 variant -- are having an impact even at the quad-core level. However, better scalability still isn't enough to offset Windows XP's huge performance edge on today's hardware. In fact, it won't be until after Windows 7 has been replaced by the next Windows that the fruit of Microsoft's multicore optimization labors will be fully realized. Then, as we boot our 32- or 64-core netbooks, we can all smile as Microsoft's foresight and perseverance finally start to pay off.