How much faster is a quad core processor than a dual 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.