You can never have too many cores

analysis
Mar 20, 20083 mins

Or be too young. Or too thin. Or too rich. It's a truism: Ever since the introduction of Windows 2000 Workstation - which was the first mainstream Windows client OS to support Symmetrical Multiprocessing (SMP) - desktop PCs have been in a position to exploit multiple CPUs and/or CPU cores. However, most early users couldn't understand why they might need or even want more than one "brain" in their syst

Or be too young. Or too thin. Or too rich.

It’s a truism: Ever since the introduction of Windows 2000 Workstation – which was the first mainstream Windows client OS to support Symmetrical Multiprocessing (SMP) – desktop PCs have been in a position to exploit multiple CPUs and/or CPU cores. However, most early users couldn’t understand why they might need or even want more than one “brain” in their systems. After all, how fast does Word need to run before you start to see diminishing returns?

Of course, what these early users didn’t see (and what many current users still fail to grasp) is the fact that there’s more going on under the hood on their PCs than just Word executing a global search/replace. Each new generation of Windows and Office has introduced additional layers of overhead – new services, malware detection, encryption/compression, auto-complete/spell-checking/formatting – that steal CPU cycles from the foreground task: Word, Excel or whatever you’re working on.

Back when I was under contract to Intel’s Desktop Architecture Labs (DAL), we even had a name for this phenomenon: “Constant Computing.” The idea was that, as software complexity grew, the number of “idle” cycles available on a given desktop would (and should) decrease. More complexity = more demand for CPU cycles. This was especially true in enterprise computing environments where a “base” system image usually included several dozen layers of agents, services and background tasks that would run in parallel with the user’s day to day application tasks.

Unfortunately, in the Windows 2000 timeframe, dual-core CPUs were still the stuff of fantasy. If you wanted SMP on your desktop you bought a system with two or more discrete CPUs – a cost-prohibitive prospect even today. However, with the introduction of competitively-priced dual-core CPUs came the first mainstream shift to SMP-based computing.

With dual-core (and now quad and even six-core) CPUs, users are finally learning what high-end SMP workstation users have known for years: That having more than one CPU allows Windows to multitask smoother and generally deliver a more responsive experience, even with lots of background services running.

With the number of cores going up (Intel plans to deliver its six-core offerings later this year), chances are that you’ll continue to see good foreground performance no matter how much enterprise computing “baggage” gets tacked onto your computing stack. All of which makes statements like “Who would want all those cores?” seem silly. As we’ve seen with Windows Vista, Microsoft is more than capable of finding a use for available CPU cycles. In fact, given the level of Windows and Office code bloat I’ve witnessed over the past few years, the better question is: “What will you do without all those cores?”

Bottom Line: You don’t need specialized, multi-threaded applications to reap the benefits of SMP support in Windows. If nothing else, those additional CPU cycles will help to offset the code bloat that threatens to bury each new generation of PC hardware. And with Microsoft at the helm, it’s a good bet we’ll all be wishing Intel would crank-up the cores-per-CPU count even faster.