Home Intel’s Core 2 Extreme QX6800 processor
Reviews

Intel’s Core 2 Extreme QX6800 processor

Scott Wasson
Disclosure
Disclosure
In our content, we occasionally include affiliate links. Should you click on these links, we may earn a commission, though this incurs no additional cost to you. Your use of this website signifies your acceptance of our terms and conditions as well as our privacy policy.

DO YOU KNOW the one about the rabbi, the chimp, the Catholic priest, and the jar of peanut butter? No? Neither do I, which is a shame, because I could use some filler material right about now. You see, I have to write a review of the Core 2 Extreme QX6800 processor. It’s not that this CPU is a boring subject per se; this is, after all, a quad-core monster that runs at 2.93GHz and costs a whopping twelve hundred dollars. It’s just that the previous fastest CPU on the planet was its predecessor, the Core 2 Extreme QX6700, and the competition from AMD wasn’t really all that close—especially once you figure in things like power consumption, motherboard selection, and overall system costs. Watching the Core 2 Extreme slice through our benchmark suite is much like watching Michael Schumacher’s Ferrari start at the pole and lead every lap to the finish in an F1 race. There may be some high-speed twists and turns along the way, but the outcome is never really in doubt.

Now that we’ve moved from the chimp and the peanut butter to the race car analogy, my work here is almost done. Can I manage to mail in the rest of this one without losing my job? Of course! I’m my own boss. Keep reading if you dare.

The QX6800’s pedigree and required reading
The uninitiated should fear not. Through the power of the web, we’ll bring you up to speed in a mere paragraph. You see, the Core 2 Extreme QX6800 is basically just a speed bump—a clock frequency increase for an existing product, not a substantially new chip. It’s based on the excellent dual-core Intel Core 2 Duo processors, first released last summer. This past fall, Intel upped the ante with a product code-named “Kentsfield” during its development. It packed a pair of Core 2 chips into a single package to yield a total of four cores in a single CPU socket. Kentsfield first came to market as the Core 2 Extreme QX6700, running at 2.66GHz, and impressed the world with its formidable number-crunching prowess. AMD countered with the dual-socket Quad FX platform, but as we noted in our review, Quad FX was saddled to a single (and pricey) motherboard choice, drew tremendous amounts of power at the wall socket, and still couldn’t perform entirely on par with the QX6700. Those same problems plague Quad FX today, as we noted when we revisited desktop quad-core solutions recently.

So the Core 2 Extreme QX6800 is positioned nicely to take the overall CPU performance crown from its predecessor and then dance around, holding it in the competition’s face and talking trash, just because it can. Beyond that, there’s only a little to know about the QX6800. I’ve already mentioned the price, all written out in words so you could absorb it slowly and avoid psychological shock. Officially, the list price is $1199, though, so I was fudging things a bit. Also, you’ll want to note that as an Extreme edition processor, this product has an unlocked upper multiplier, which means it’s very easy to overclock. Once you’ve paid the ransom for their fastest CPU, the folks at Intel see no reason to stand in your way. Unfortunately, the laws of physics tend to think differently on that subject—the real frequency headroom is typically found in lower speed chips.


The Core 2 Extreme QX6800. ‘taint much to look at.

If you were looking for things to say about it, you could say that the QX6800 is a milestone of sorts in several ways. This is really the first speed bump we’ve seen for the Core 2 series since Intel introduced it last July. The dual-core Core 2 Extreme X6800 started life at 2.93GHz, and Intel has elected to add cores rather than ratchet up the clock speed since then. Thanks to that strategy, the QX6800 has caught up with its dual-core siblings in terms of clock frequency. This situation may not last forever, but as of now, even single-threaded games and applications will run as quickly on this top-end CPU as on any other from Intel.

The QX6800 represents progress on the power efficiency and thermal fronts, too. Despite its higher clock speed, it’s rated at the same 130W TDP as the QX6700 before it. Intel has no doubt refined its 65nm manufacturing progress since the QX6700’s debut, and that allows this speed bump to fit into the same thermal envelope as its predecessor. To be clear, 130W is not a thermal window through which minty-cool breezes waft. You will need a substantial air cooler to keep the QX6800 happy without making too much racket. But a hefty TDP rating doesn’t necessarily equate to poor energy efficiency, as our test results will illustrate.

 

Our testing methods
As ever, we did our best to deliver clean benchmark numbers. Tests were run at least three times, and the results were averaged.

In some cases, getting the results meant simulating a slower chip with a faster one. For instance, our Core 2 Duo E6600 and E6700 processors are actually a Core 2 Extreme X6800 processor clocked down to the appropriate speeds. Their performance should be identical to that of the real thing. Similarly, our Athlon 64 FX-72 results come from an underclocked pair of Athlon 64 FX-74s, our Athlon 64 X2 4400+ is an underclocked X2 5000+ (both 65nm), and our Athlon 64 X2 5600+ is an underclocked Athlon 64 X2 6000+.

Our test systems were configured like so:

Processor Core 2 Duo E6300 1.83GHz
Core 2 Duo E6400 2.13GHz
Core 2 Duo E6600 2.4GHz
Core 2 Duo E6700 2.66GHz
Core 2 Extreme X6800 2.93GHz
Core 2 Quad Q6600 2.4GHz
Core 2 Extreme QX6700 2.66GHz
Core 2 Extreme QX6800 2.93GHz
Athlon 64 X2 3600+ 1.9GHz (65nm)
Athlon 64 X2 4400+ 2.3GHz (65nm)
Athlon 64 X2 5000+ 2.6GHz (65nm)
Athlon 64 X2 5000+ 2.6GHz (90nm)
Athlon 64 X2 5600+ 2.8GHz (90nm)
Athlon 64 X2 6000+ 3.0GHz (90nm)
Athlon 64 FX-70 2.6GHz
Athlon 64 FX-72 2.8GHz
Athlon 64 FX-74 3.0GHz
System bus 1066MHz (266MHz quad-pumped) 1GHz HyperTransport 1GHz HyperTransport
Motherboard Intel D975XBX2 Asus M2N32-SLI Deluxe Asus L1N64-SLI WS
BIOS revision BX97520J.86A.2618.2007.0212.0954 0903 0205
North bridge 975X MCH nForce 590 SLI SPP nForce 680a SLI
South bridge ICH7R nForce 590 SLI MCP nForce 680a SLI
Chipset drivers INF Update 8.1.1.1010
Intel Matrix Storage Manager 6.21
ForceWare 15.00 ForceWare 15.00
Memory size 2GB (2 DIMMs) 2GB (2 DIMMs) 2GB (4 DIMMs)
Memory type Corsair TWIN2X2048-6400C4
DDR2 SDRAM
at 800MHz
Corsair TWIN2X2048-8500C5
DDR2 SDRAM
at 800MHz
Crucial Ballistix PC6400
DDR2 SDRAM
at 800MHz
CAS latency (CL) 4 4 4
RAS to CAS delay (tRCD) 4 4 4
RAS precharge (tRP) 4 4 4
Cycle time (tRAS) 12 12 12
Audio Integrated ICH7R/STAC9274D5 with
Sigmatel 6.10.0.5274 drivers
Integrated nForce 590 MCP/AD1988B with
Soundmax 6.10.2.6100 drivers
Integrated nForce 680a SLI/AD1988B with
Soundmax 6.10.2.6100 drivers
Hard drive Maxtor DiamondMax 10 250GB SATA 150
Graphics GeForce 7900 GTX 512MB PCIe with ForceWare 100.64 drivers
OS Windows Vista Ultimate x64 Edition
OS updates

Our Core 2 Duo E6400 processor came to us courtesy of the fine folks up north at NCIX. Those of you who are up in Canada will definitely want to check them out as potential source of PC hardware and related goodies.

Thanks to Corsair for providing us with memory for our testing. Their products and support are far and away superior to generic, no-name memory.

Also, all of our test systems were powered by OCZ GameXStream 700W power supply units. Thanks to OCZ for providing these units for our use in testing.

The test systems’ Windows desktops were set at 1280×1024 in 32-bit color at an 85Hz screen refresh rate. Vertical refresh sync (vsync) was disabled.

We used the following versions of our test applications:

The tests and methods we employ are generally publicly available and reproducible. If you have questions about our methods, hit our forums to talk with us about them.

 

The Elder Scrolls IV: Oblivion
We tested Oblivion by manually playing through a specific point in the game five times while recording frame rates using the FRAPS utility. Each gameplay sequence lasted 60 seconds. This method has the advantage of simulating real gameplay quite closely, but it comes at the expense of precise repeatability. We believe five sample sessions are sufficient to get reasonably consistent results. In addition to average frame rates, we’ve included the low frame rates, because those tend to reflect the user experience in performance-critical situations. In order to diminish the effect of outliers, we’ve reported the median of the five low frame rates we encountered.

For this test, we set Oblivion‘s graphical quality to “Medium” but with HDR lighting enabled and vsync disabled, at 800×600 resolution. We’ve chosen this relatively low display resolution in order to prevent the graphics card from becoming a bottleneck, so differences between the CPUs can shine through.

Notice the little green plot with four lines above the benchmark results. That’s a snapshot of the CPU utilization indicator in Windows Task Manager, which helps illustrate how much the application takes advantage of up to four CPU cores, when they’re available. I’ve included these Task Manager graphics whenever possible throughout our results. In this case, Oblivion really only takes full advantage of a single CPU core, although Nvidia’s graphics drivers use multithreading to offload some vertex processing chores.

Thus begins a long series of tests results in which the Core 2 Extreme QX6800 leads the field in performance. For what it’s worth, I don’t think the game here is using more than two cores; the QX6800 is just faster than its dual-core X6800 counterpart by a few frames per second due to the natural variations that come with manual gameplay testing. The numbers say it, but any of these CPUs will run Oblivion at acceptable frame rates—even the bargain-basement Athlon 64 X2 3600+.

Rainbow Six: Vegas
Rainbow Six: Vegas is based on Unreal Engine 3 and is a port from the Xbox 360. For both of these reasons, it’s one of the first PC games that’s multithreaded, and it ought to provide an illuminating look at CPU gaming performance.

For this test, we set the game to run at 800×600 resolution with high dynamic range lighting disabled. “Hardware skinning” (via the GPU) was disabled, leaving that burden to fall on the CPU. Shadow quality was set to very low, and motion blur was enabled at medium quality. I played through a 90-second sequence of the game’s Terrorist Hunt mode on the “Dante’s” level five times, capturing frame rates with FRAPS, as we did with Oblivion.

The top finishers bunch up tightly again in R6: Vegas, and the QX6800 again leads the pack. Its most direct competition, the Quad FX-based Athlon 64 FX-74, trails by three frames per second—practically nothing.

 

Supreme Commander
This game is multithreaded and can actually take advantage of more than two processor cores, making it a rare commodity indeed. We ran into some snags when we first tried to test this game with FRAPS. Getting consistent results proved difficult, and the sound didn’t want to work on our Intel D975XBX2 motherboard, whose Vista x64 audio drivers may not yet be up to snuff. I was also developing the first signs of extreme RTS addiction—a grave condition indeed. I found myself analyzing unit types and lusting after level-two engineer bots. Fortunately, we were able to overcome these problems by using Supreme Commander‘s very nice built-in benchmark, which plays back a test game and reports detailed performance results afterward. We launched the benchmark by running the game with the “/map perftest /nosound” options. (Normally, we prefer to test games with audio enabled, but we made an exception here.) We tested at 1024×768 resolution with the game’s default quality settings.

Supreme Commander’s built-in benchmark breaks down its results into several major categories: running the game’s simulation, rendering the game’s graphics, and a composite score that’s simply comprised of the other two. The performance test also reports good ol’ frame rates, so we’ve included those, as well.

Yep, you guessed it, the QX6800 is fastest across the board. Who’d have thought? As you may have noticed, our results for the render test and the FPS numbers look to be limited somewhat by the graphics card we used. We did try testing with a GeForce 8800 GTS, as well, and still found little separation between the Core 2 Duo E6300 and the Core 2 Extreme QX6700. Next time out, we’ll probably test this game in a different way to see if we can tease out larger differences between the CPUs.

 

Valve Source engine particle simulation
Next up are a couple of tests we picked up during a visit to Valve Software, the developers of the Half-Life games. They’ve been working to incorporate support for multi-core processors into their Source game engine, and they’ve cooked up a couple of benchmarks to demonstrate the benefits of multithreading.

The first of those tests runs a particle simulation inside of the Source engine. Most games today use particle systems to create effects like smoke, steam, and fire, but the realism and interactivity of those effects is limited by the available computing horsepower. Valve’s particle system distributes the load across multiple CPU cores.

Once games come around to using four cores in a meaningful way—and it looks like Valve’s Source engine will make that happen—the QX6800 will be well positioned to take advantage.

Valve VRAD map compilation
This next test processes a map from Half-Life 2 using Valve’s VRAD lighting tool. Valve uses VRAD to precompute lighting that goes into its games. This isn’t a real-time process, and it doesn’t reflect the performance one would experience while playing a game. It does, however, show how multiple CPU cores can speed up game development.

Were you expecting anything else? The QX6800 sticks to the top spot like peanut butter to the roof of your mouth.

(Wait for it. I’m working on the chimp, the priest, and the rabbi.)

 

3DMark06
3DMark06 combines the results from its graphics and CPU tests in order to reach an overall score. Here’s how the processors did overall and in each of those tests.

3DMark’s graphics tests are, as expected, graphics bound. But its CPU tests help determine the overall 3DMark score, and those tests are nicely multithreaded. The QX6800 edges out the Athlon 64 FX-74, as does the QX6700.

 

The Panorama Factory
The Panorama Factory handles an increasingly popular image processing task: joining together multiple images to create a wide-aspect panorama. This task can require lots of memory and can be computationally intensive, so The Panorama Factory comes in a 64-bit version that’s multithreaded. I asked it to join four pictures, each eight megapixels, into a glorious panorama of the interior of Damage Labs. The program’s timer function captures the amount of time needed to perform each stage of the panorama creation process. I’ve also added up the total operation time to give us an overall measure of performance.

picCOLOR
picCOLOR was created by Dr. Reinert H. G. Müller of the FIBUS Institute. This isn’t Photoshop; picCOLOR’s image analysis capabilities can be used for scientific applications like particle flow analysis. Dr. Müller has supplied us with new revisions of his program for some time now, all the while optimizing picCOLOR for new advances in CPU technology, including MMX, SSE2, and Hyper-Threading. Naturally, he’s ported picCOLOR to 64 bits, so we can test performance with the x86-64 ISA. Eight of the 12 functions in the test are multithreaded, and in this latest revision, five of those eight functions use four threads.

Scores in picCOLOR, by the way, are indexed against a single-processor Pentium III 1 GHz system, so that a score of 4.14 works out to 4.14 times the performance of the reference machine.

Phew. That’s a lotta numbers, and they all look very good for the QX6800—which is, incidentally, nearly 15 times faster in picCOLOR than the reference 1GHz Pentium III processor.

 

Windows Media Encoder x64 Edition
Windows Media Encoder is one of the few popular video encoding tools that uses four threads to take advantage of quad-core systems, and it comes in a 64-bit version. For this test, I asked Windows Media Encoder to transcode a 153MB 1080-line widescreen video into a 720-line WMV using its built-in DVD/Hardware profile. Because the default “High definition quality audio” codec threw some errors in Windows Vista, I instead used the “Multichannel audio” codec. Both audio codecs have a variable bitrate peak of 192Kbps.

LAME MP3 encoding
LAME MT is a multithreaded version of the LAME MP3 encoder. LAME MT was created as a demonstration of the benefits of multithreading specifically on a Hyper-Threaded CPU like the Pentium 4. Of course, multithreading works even better on multi-core processors. You can download a paper (in Word format) describing the programming effort.

Rather than run multiple parallel threads, LAME MT runs the MP3 encoder’s psycho-acoustic analysis function on a separate thread from the rest of the encoder using simple linear pipelining. That is, the psycho-acoustic analysis happens one frame ahead of everything else, and its results are buffered for later use by the second thread. That means this test won’t really use more than two CPU cores.

We have results for two different 64-bit versions of LAME MT from different compilers, one from Microsoft and one from Intel, doing two different types of encoding, variable bit rate and constant bit rate. We are encoding a massive 10-minute, 6-second 101MB WAV file here, as we have done in many of our previous CPU reviews.

Yeah, I’ve got nothing. Let’s move on.

 

Cinebench
Graphics is a classic example of a computing problem that’s easily parallelizable, so it’s no surprise that we can exploit a multi-core processor with a 3D rendering app. Cinebench is the first of those we’ll try, a benchmark based on Maxon’s Cinema 4D rendering engine. It’s multithreaded and comes with a 64-bit executable. This test runs with just a single thread and then with as many threads as CPU cores are available.

Hey, look, actual drama: the FX-74 was ahead of the Core 2 Extreme QX6700 here, but the QX6800 recaptures the lead for Intel.

POV-Ray rendering
We’ve finally caved in and moved to the beta version of POV-Ray 3.7 that includes native multithreading. The latest beta 64-bit executable is still quite a bit slower than the 3.6 release, but it should give us a decent look at comparative performance, regardless.

Shockingly, the QX6800 is not at the very top for once, although it’s close. The FX-74 finishes rendering the scene 10 seconds sooner.

Things snap back into line with POV-Ray’s official benchmark scene, which uses several features that the older Chess2 scene does not. The FX-74 isn’t far behind here, though, and it is ahead of the QX6700.

 

MyriMatch
Our benchmarks sometimes come from unexpected places, and such is the case with this one. David Tabb is a friend of mine from high school and a long-time TR reader. He recently offered to provide us with an intriguing new benchmark based on an application he’s developed for use in his research work. The application is called MyriMatch, and it’s intended for use in proteomics, or the large-scale study of protein. I’ll stop right here and let him explain what MyriMatch does:

In shotgun proteomics, researchers digest complex mixtures of proteins into peptides, separate them by liquid chromatography, and analyze them by tandem mass spectrometers. This creates data sets containing tens of thousands of spectra that can be identified to peptide sequences drawn from the known genomes for most lab organisms. The first software for this purpose was Sequest, created by John Yates and Jimmy Eng at the University of Washington. Recently, David Tabb and Matthew Chambers at Vanderbilt University developed MyriMatch, an algorithm that can exploit multiple cores and multiple computers for this matching. Source code and binaries of MyriMatch are publicly available.

In this test, 5555 tandem mass spectra from a Thermo LTQ mass spectrometer are identified to peptides generated from the 6714 proteins of S. cerevisiae (baker’s yeast). The data set was provided by Andy Link at Vanderbilt University. The FASTA protein sequence database was provided by the Saccharomyces Genome Database.

MyriMatch uses threading to accelerate the handling of protein sequences. The database (read into memory) is separated into a number of jobs, typically the number of threads multiplied by 10. If four threads are used in the above database, for example, each job consists of 168 protein sequences (1/40th of the database). When a thread finishes handling all proteins in the current job, it accepts another job from the queue. This technique is intended to minimize synchronization overhead between threads and minimize CPU idle time.

The most important news for us is that MyriMatch is a widely multithreaded real-world application that we can use with a relevant data set. MyriMatch also offers control over the number of threads used, so we’ve tested with one to four threads. Also, this is a newer version of the MyriMatch code than we’ve used in the past, with a larger spectral collection, so these results aren’t comparable to those in some of our past articles.

Although the Quad FX systems appear to run into scaling issues with four threads in this application, Intel’s quad-core processors have no such trouble, and the QX6800 is all alone in first place once again.

STARS Euler3d computational fluid dynamics
Our next benchmark is also a relatively new one for us. Charles O’Neill works in the Computational Aeroservoelasticity Laboratory at Oklahoma State University, and he contacted us recently to suggest we try the computational fluid dynamics (CFD) benchmark based on the STARS Euler3D structural analysis routines developed at CASELab. This benchmark has been available to the public for some time in single-threaded form, but Charles was kind enough to put together a multithreaded version of the benchmark for us with a larger data set. He has also put a web page online with a downloadable version of the multithreaded benchmark, a description, and some results here. (I believe the score you see there at almost 3Hz comes from our eight-core Clovertown test system.)

In this test, the application is basically doing analysis of airflow over an aircraft wing. I will step out of the way and let Charles explain the rest:

The benchmark testcase is the AGARD 445.6 aeroelastic test wing. The wing uses a NACA 65A004 airfoil section and has a panel aspect ratio of 1.65, taper ratio of 0.66, and a quarter-chord sweep angle of 45º. This AGARD wing was tested at the NASA Langley Research Center in the 16-foot Transonic Dynamics Tunnel and is a standard aeroelastic test case used for validation of unsteady, compressible CFD codes.

The CFD grid contains 1.23 million tetrahedral elements and 223 thousand nodes . . . . The benchmark executable advances the Mach 0.50 AGARD flow solution. A benchmark score is reported as a CFD cycle frequency in Hertz.

So the higher the score, the faster the computer. I understand the STARS Euler3D routines are both very floating-point intensive and oftentimes limited by memory bandwidth. Charles has updated the benchmark for us to enable control over the number of threads used. Here’s how our contenders handled the test with different thread counts.

Here’s proof positive. If you want a supercomputer on your desktop, the QX6800 is the way to go.

 

Folding@Home
Next, we have another relatively new addition to our benchmark suite: a slick little Folding@Home benchmark CD created by notfred, one of the members of Team TR, our excellent Folding team. For the unfamiliar, Folding@Home is a distributed computing project created by folks at Stanford University that investigates how proteins work in the human body, in an attempt to better understand diseases like Parkinson’s, Alzheimer’s, and cystic fibrosis. It’s a great way to use your PC’s spare CPU cycles to help advance medical research. I’d encourage you to visit our distributed computing forum and consider joining our team if you haven’t already joined one.

The Folding@Home project uses a number of highly optimized routines to process different types of work units from Stanford’s research projects. The Gromacs core, for instance, uses SSE on Intel processors, 3DNow! on AMD processors, and Altivec on PowerPCs. Overall, Folding@Home should be a great example of real-world scientific computing.

notfred’s Folding Benchmark CD tests the most common work unit types and estimates performance in terms of the points per day that a CPU could earn for a Folding team member. The CD itself is a bootable ISO. The CD boots into Linux, detects the system’s processors and Ethernet adapters, picks up an IP address, and downloads the latest versions of the Folding execution cores from Stanford. It then processes a sample work unit of each type.

On a system with two CPU cores, for instance, the CD spins off a Tinker WU on core 1 and an Amber WU on core 2. When either of those WUs are finished, the benchmark moves on to additional WU types, always keeping both cores occupied with some sort of calculation. Should the benchmark run out of new WUs to test, it simply processes another WU in order to prevent any of the cores from going idle as the others finish. Once all four of the WU types have been tested, the benchmark averages the points per day among them. That points-per-day average is then multiplied by the number of cores on the CPU in order to estimate the total number of points per day that CPU might achieve.

This may be a somewhat quirky method of estimating overall performance, but my sense is that it generally ought to work. We’ve discussed some potential reservations about how it works here, for those who are interested. I have included results for each of the individual WU types below, so you can see how the different CPUs perform on each.

More drama! The QX6800 edges out the FX-74, grabbing the overall lead for Intel. The Core 2 processors were already clearly the fastest CPUs for the two Gromacs WU types, which tend to be pretty common these days.

 

SiSoft Sandra Mandelbrot
Next up is SiSoft’s Sandra system diagnosis program, which includes a number of different benchmarks. The one of interest to us is the “multimedia” benchmark, intended to show off the benefits of “multimedia” extensions like MMX, SSE, and SSE2. According to SiSoft’s FAQ, the benchmark actually does a fractal computation:

This benchmark generates a picture (640×480) of the well-known Mandelbrot fractal, using 255 iterations for each data pixel, in 32 colours. It is a real-life benchmark rather than a synthetic benchmark, designed to show the improvements MMX/Enhanced, 3DNow!/Enhanced, SSE(2) bring to such an algorithm.

The benchmark is multi-threaded for up to 64 CPUs maximum on SMP systems. This works by interlacing, i.e. each thread computes the next column not being worked on by other threads. Sandra creates as many threads as there are CPUs in the system and assignes [sic] each thread to a different CPU.

We’re using the 64-bit version of Sandra. The “Integer x16” version of this test uses integer numbers to simulate floating-point math. The floating-point version of the benchmark takes advantage of SSE2 to process up to eight Mandelbrot iterations in parallel.

I like to keep this one around as example of what happens when you get a highly parallelizable workload going with lots of vector math optimizations like SSE2. Right now, the Core microarchitecture has a natural performance advantage in running this type of code. Of course the QX6800 dominates here, as one would expect.

 

Power consumption and efficiency
We’re trying something a little different with power consumption. Our Extech 380803 power meter has the ability to log data, so we can capture power use over a span of time. The meter reads power use at the wall socket, so it incorporates power use from the entire system—the CPU, motherboard, memory, video card, hard drives, and anything else plugged into the power supply unit. (We plugged the computer monitor and speakers into a separate outlet, though.) We measured how each of our test systems used power during a roughly one-minute period, during which time we executed Cinebench’s multithreaded rendering test. All of the systems had their power management features (such as SpeedStep and Cool’n’Quiet) enabled during these tests.

You’ll notice that I’ve not included the Athlon 64 FX-72 here. That’s because our “simulated” FX-72 CPUs are underclocked versions of faster processors, and we’ve not been able to get Cool’n’Quiet power-saving tech to work when CPU multiplier control is in use. I have included test results for genuine Athlon 64 X2 4400+ and 5600+ chips, as promised in our last CPU roundup.

I have included our simulated Core 2 Duo E6600 and E6700, because SpeedStep works fine on the D975XBX2 motherboard alongside underclocking. The simulated processors’ voltage may not be exactly the same as what you’d find on many retail E6600s and E6700s. However, voltage and power use can vary from one chip to the next, since Intel sets voltage individually on each chip at the factory.

The differences between the CPUs are immediately obvious by looking at these plots of the raw data. We can slice up the data in various ways in order to better understand them, though. We’ll start with a look at idle power, taken from the trailing edge of our test period, after all CPUs have completed the render.

There’s no hiding the presence of a second chip on the QX6800’s package, even at idle. It simply draws more power than the dual-core Core 2 CPUs. That said, our QX6800 draws six fewer watts at idle than our Core 2 Extreme QX6700.

Next, we can look at peak power draw by taking an average from the five-second span from 10 to 15 seconds into our test period, during which the processors were rendering.

Impressively, the QX6800 pulls only 2W more juice under load than its predecessor—and the top Intel quad-core system draws less power than the Athlon 64 X2 6000+-based rig.

Another way to gauge power efficiency is to look at total energy use over our time span. This method takes into account power use both during the render and during the idle time. We can express the result in terms of watt-seconds, also known as joules.

The QX6800 finishes middle of the pack in energy use over the test time period, ahead of the QX6700. That’s largely because it finishes the render first and thus drops back down to idle power levels sooner. Power use on the Quad FX systems is… embarrassing.

We can quantify efficiency even better by considering the amount of energy used to render the scene. Since the different systems completed the render at different speeds, we’ve isolated the render period for each system. We’ve chosen to identify the end of the render as the point where power use begins to drop from its steady peak. There seems to be some disk paging going on after that, but we don’t want to include that more variable activity in our render period.

We’ve computed the amount of energy used by each system to render the scene. This method should account for both power use and, to some degree, performance, because shorter render times may lead to less energy consumption.

This result encapsulates nicely the progress Intel has made on power efficiency since our QX6700 was manufactured. The QX6800 draws about the same amount of power while running at a higher clock frequency, allowing it to complete the task using less total energy than the QX6700. What’s more, the Intel Kentsfield quad-core processors are the most energy efficient in this test, since this workload can be broken into four parallel threads with ease.

 
Overclocking
We were able to get our Core 2 Extreme QX6700 running at 3.2GHz back when we reviewed it, so I expected big things for the QX6800—at least 3.46GHz should be possible, right? After all, the QX6700 would post at 3.46GHz and begin booting Windows before things went sideways.

Unfortunately, the QX6800 didn’t do much better. I was able to get it booting into Windows at 3.46GHz with just a minor voltage tweak, but it was very shaky. Raising the voltage from 1.375V to 1.4V didn’t help. Neither did 1.4125, 1.425, or 1.4375V. The thing just wouldn’t quite stay stable. One of the four cores, in particular, threw errors in Prime95 pretty quickly at 3.46GHz, seemingly no matter what. I contemplated going higher with the voltage, but two things held me back. One was the fact that adding voltage seemed to be making things worse, not better. The other was the awe-inspiring price tag on this CPU.

And I was just using air cooling, although it was a very large air cooler with a fast fan running full-tilt. I wouldn’t be entirely shocked to see this CPU become stable at 3.46GHz with good water cooling or the like.

Here’s our officially official proof of overclocking success, the CPU-Z screenshot.

I also ran a couple of benchmarks at 3.2GHz, just to prove that the QX6800 overclocked is even, uh, fasterer.

That’s what mine did, anyhow. Your mileage may vary.

 
Conclusions
You may have gathered that the Core 2 Extreme QX6800 is the fastest desktop processor that money can buy. No nuance is required to discuss this one. The QX6800 nearly swept our entire benchmark suite, and in many cases, it crushed its main rival, the Athlon 64 FX-74. As one test result showed us, Intel’s new top quad-core processor achieves nearly 15 times the performance of a 1GHz Pentium III. To an old-timer like me, that stat puts this beast into perspective perhaps more than any other. This thing is an absolute wonder of Moore’s Law.

Having said that, I can’t exactly recommend purchasing one of these to have as your own. The thing costs twelve hundred dollars, for crying out loud. And this time around, unlike many others, the new Extreme edition processor doesn’t supplant its precursor. The Core 2 Extreme QX6700 lives on at $999, with an unlocked multiplier just like the QX6800. All you’re really getting for the additional $200 is a slight bump in guaranteed clock speed. Both of ’em will probably hit at least 3.2GHz just fine, if our overclocking experience is anything to go by.

Then again, relative value may not be the most notable consideration in the realm of thousand-dollar CPUs.

Just make sure you don’t take from our test results that you need a quad-core CPU today. Check our gaming test results again, in particular; few of today’s games require even a high-end dual-core CPU to perform well. Yes, many of our tests showed big performance gains from going quad, but our benchmark suite was designed to show the potential of these processors. If you simply stick with more common applications, well, you may have trouble getting them to take full advantage of two cores, let alone four.

Unless, that is, you have a chimp, a priest, a rabbi, and a jar of peanut butter. Then it’s a whole other story.