Choosing Dual or Quad Core

I'm a big fan of dual-core systems. I think there's a clear and substantial benefit for all computer users when there are two CPUs waiting to service requests, instead of just one. If nothing else, it lets you gracefully terminate an application that has gone haywire, consuming all available CPU time. It's like having a backup CPU in reserve, waiting to jump in and assist as necessary. But for most software, you hit a point of diminishing returns very rapidly after two cores. In Quad-Core Desktops and Diminishing Returns, I questioned how effectively today's software can really use even four CPU cores, much less the inevitable eight and sixteen CPU cores we'll see a few years from now.

To get a sense of what kind of performance improvement we can expect going from 2 to 4 CPU cores, let's focus on the Core 2 Duo E6600 and Core 2 Quad Q6600 processors. These 2.4 GHz CPUs are identical in every respect, except for the number of cores they bring to the table. In a recent review, Scott Wasson at the always-thorough Tech Report presented a slew of benchmarks that included both of these processors. Here's a quick visual summary of how much you can expect performance to improve when upgrading from 2 to 4 CPU cores:

Task Manager CPU Graph improvement
2 to 4 cores
The Elder Scrolls IV: Oblivion none
Rainbow 6: Vegas none
Supreme Commander none
Valve Source engine particle simulation 1.8 x
Valve VRAD map compilation 1.9 x
3DMark06: Return to Proxycon none
3DMark06: Firefly Forest none
3DMark06: Canyon Flight none
3DMark06: Deep Freeze none
3DMark06: CPU test 1 1.7 x
3DMark06: CPU test 2 1.6 x
The Panorama Factory 1.6 x
picCOLOR 1.4 x
Windows Media Encoder x64 1.6 x
Lame MT MP3 encoder none
Cinebench 1.7 x
POV-Ray 2.0 x
Myrimatch 1.8 x
STARS Euler3D 1.5 x
SiSoft Sandra Mandelbrot 2.0 x

The results seem encouraging, until you take a look at the applications that benefit from quad-core-- the ones that aren't purely synthetic benchmarks are rendering, encoding, or scientific applications . It's the same old story. Beyond encoding and rendering tasks which are naturally amenable to parallelization, the task manager CPU graphs tell the sad tale of software that simply isn't written to exploit more than two CPUs.

Unfortunately, CPU parallelism is inevitable. Clock speed can't increase forever; the physics don't work. Mindlessly ramping clock speed to 10 GHz isn't an option. CPU vendors are forced to deliver more CPU cores running at nearly the same clock speed, or at very small speed bumps. Increasing the number of CPU cores on a die should defeat raw clock speed increases, at least in theory. In the short term, we have to choose between faster dual-core systems, or slower quad-core systems. Today, a quad-core 2.4 GHz CPU costs about the same as a dual-core 3.0 GHz CPU. But which one will provide superior performance? A recent Xbit Labs review performed exactly this comparison:

3.0 GHz
Dual Core
2.4 GHz
Quad Core
improvement
2 to 4 cores 
PCMark05  9091 8853 -3%
SysMark 2007, E-Learning 167 140 -16%
SysMark 2007, Video Creation 131 151 15%
SysMark 2007, Productivity 152 138 -9%
SysMark 2007, 3D 160 148 -8%
Quake 4 136 117 -15%
F.E.A.R. 123 110 -10%
Company of Heroes 173 161 -7%
Lost Planet 62 54 -12%
Lost Planet "Concurrent Operations" 62 81 30%
DivX 6.6 65 64 0%
Xvid 1.2 43 45 5%
H.264 QuickTime Pro 7.2 189 188 0%
iTunes 7.3 MP3 encoding 110 131 -16%
3ds Max 9 SP2 4.95 6.61 33%
Cinebench 10 5861 8744 49%
Excel 2007 39.9 24.4 63%
WinRAR 3.7 188 180 5%
Photoshop CS3 70 73 -4%
Microsoft Movie Maker 6.0 73 80 -9%

It's mostly what I would expect-- only rendering and encoding tasks exploit parallelism enough to overcome the 25% speed deficit between the dual and quad core CPUs. Outside of that specific niche, performance will actually suffer for most general purpose software if you choose a slower quad-core over a faster dual-core.

However, there were some surprises in here, such as Excel 2007, and the Lost Planet "concurrent operations" setting. It's possible software engineering will eventually advance to the point that clock speed matters less than parallelism. Or eventually it might be irrelevant, if we don't get to make the choice between faster clock speeds and more CPU cores. But in the meantime, clock speed wins most of the time. More CPU cores isn't automatically better. Typical users will be better off with the fastest possible dual-core CPU they can afford.