Intel’s Core 2 Duo E6750 processor

INTEL FIRST UNCORKED its Core 2 processors last July, and believe it or not, relatively little has changed since then. Oh, sure, they’ve introduced quad-core variants of those processors that are essentially two chips in one package and a few low-end parts, but that’s about it. The top-speed-grade Core 2 processor last July was the Core 2 Extreme X6800 at 2.93GHz, and it remains the top speed grade today. That’s a remarkable amount of stability in a year’s time, but then the Core 2 hasn’t needed much help—AMD hasn’t yet caught up to it in performance.

Few things sit still in these parts for long, though, and things are about to change once again, as Intel’s recent introduction of the P35 Express chipset signaled. The new P35 and upcoming X38 chipsets from Intel are capable of supporting front-side bus speeds of 1333MHz, and Intel plans to introduce a slew of Core 2 processors primed for the faster bus. Although those CPUs won’t officially debut until later this summer, we have a preview today of one of those chips, the Core 2 Duo E6750. We have, of course, run the E6750 through our gamut of CPU performance tests, and we’ve also checked out its overclocking potential—which turns out to be rather considerable.

Meet the E6750
The Core 2 Duo E6750 is not a complex, brooding character from a French existentialist novel. Its story is rather simple. Like the E6700 before it, the E6750 is manufactured on a 65nm fab process and runs at a stock clock speed of 2.66GHz. Although its bus speed has jumped from 1066MHz to 1333MHz, its thermal design power (TDP) rating is unchanged at 65W. The E6750 is even compatible with LGA775-style sockets, though it does require a motherboard that supports its faster bus frequency.

I’d be more than happy to tell you what the price of the E6750 will be, but since it’s not officially announced yet, Intel is keeping mum on that front. Here’s a guess for you: it will be priced similarly to the current Core 2 Duo E6700, unless Intel decides to pull the trigger on a rumored across-the-board price cut when the product is announced.

In other words, I dunno exactly, but I wouldn’t expect to pay a premium for the higher bus speed.

We’ve tested the Core 2 Duo E6750 on the Asus P5K Deluxe motherboard, which is based on the P35 Express chipset and has full support for 1333MHz bus speeds. The mobo we chose makes use of DDR2 memory, which is fine for our purposes, especially since the board’s dual channels of DDR2 800MHz memory offer more than enough bandwidth to keep a 1333MHz bus fed. However, DDR3 memory does offer the prospect of even higher bandwidth and some dizzying memory clock speeds. If you’d like to get a look at DDR3’s potential, let me direct you to our P35 Express review.

What you will find on the following pages is an extensive, detailed, and broad-based comparison of the Core 2 Duo E6750 to a whole host of current CPUs from AMD and Intel. We’re able to offer this comparison by plugging the E6750’s scores into a bunch of results accumulated from past reviews, so you have a very clear sense of what the move to a 1333MHz bus yields in terms of performance. With that said, I’ll be the first to admit that our current test suite—widely multithreaded and largely 64-bit though it is—is getting into its rhinestone Elvis phase and will have to be revamped before too long with new applications, new drivers, and the like.

If you’re impatient, you may want to jump straight to our overclocking results, which is where the real fun is. I promise, doing so won’t hurt my feelings. Too much.

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
Core 2 Duo E6750 2.66GHz 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
Core 2 Duo E4300 1.8GHz Athlon X2 BE-2350 2.1GHz
System bus 1066MHz (266MHz quad-pumped) 1333MHz (333MHz quad-pumped) 1GHz HyperTransport 1GHz HyperTransport
Motherboard Intel D975XBX2 Asus P5K Deluxe Asus M2N32-SLI Deluxe Asus L1N64-SLI WS
BIOS revision BX97520J.86A.2618.2007.0212.0954 0311 0903 0205
BX97520J.86A.2747.2007.0523.1129 1004
North bridge 975X Express MCH P35 Express MCH nForce 590 SLI SPP nForce 680a SLI
South bridge ICH7R ICH9R nForce 590 SLI MCP nForce 680a SLI
Chipset drivers INF Update 8.1.1.1010
Intel Matrix Storage Manager 6.21
INF Update 8.3.0.1013
Intel Matrix Storage Manager 7.5
ForceWare 15.00 ForceWare 15.00
Memory size 2GB (2 DIMMs) 2GB (2 DIMMs) 2GB (2 DIMMs) 2GB (4 DIMMs)
Memory type Corsair TWIN2X2048-6400C4
DDR2 SDRAM
at 800MHz
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 4
RAS to CAS delay (tRCD) 4 4 4 4
RAS precharge (tRP) 4 4 4 4
Cycle time (tRAS) 12 12 12 12
Audio Integrated ICH7R/STAC9274D5
with Sigmatel 6.10.0.5274 drivers
Integrated ICH9R/AD1988B
with Soundmax 6.10.2.6180 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 a 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.

Memory subsystem performance
Since we’re dealing with a faster front-side bus, we’ll start things off by looking at memory performance. The Core 2 Duo must traverse its FSB in order to reach main memory, and that bus is theoretically a clear bandwidth constraint. At 1066MHz, the Core 2 Duo’s bus offers 8.5GB/s of peak throughput, while the two channels of DDR2 memory available on most motherboards top out at 12.8GB/s of aggregate bandwidth. The E6750’s 1333MHz bus raises the ante to 10.6GB/s—not quite enough to match the memory subsystem, but a substantial improvement nonetheless. Here’s how the E6750 handles our synthetic memory bandwidth and latency benchmarks.

The Athlon 64 remains the leader in these tests by virtue of its integrated memory controller, which does away with the front-side bus altogether. The E6750, though, easily outclasses any of the 1066MHz-bus Core 2 processors in memory bandwidth, with no additional cost in latency.

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.

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 first thing we should say about these results is that most of these CPUs don’t appear to be a performance constraint in either game. That was certainly my experience while playing these games during testing. The E6750 does appear to offer a measurable performance boost over the other Core 2 Duo processors in Oblivion, although it’s very slight.

Supreme Commander
This game is multithreaded and can actually take advantage of more than two processor cores, making it a rare commodity indeed. We tested performance 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.

The faster bus on the E6750 confers only a minuscule advantage over the E6700 in Supreme Commander, another game whose performance doesn’t seem to be especially CPU-bound with today’s processors. That small boost is all the E6750 needs to place it near the top of the pack of dual-core processors, just below the Core 2 Extreme X6800 and Intel’s two quad-core Extreme Edition processors.

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 are limited by the available computing horsepower. Valve’s particle system distributes the load across multiple CPU cores.

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.

The faster bus doesn’t work wonders in either of our Valve benchmarks, as the E6750 places only an eyelash ahead of the E6700. We should probably pause to consider another factor that hasn’t changed much: the E6750 is still miles ahead of AMD’s top dual-core processor, the Athlon 64 X2 6000+.

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.

The E6750 actually drops behind the E6700 by a handful of points in 3DMark’s overall score. That’s due to it giving up a few hundredths of a second to the E6700 in 3DMark’s graphics tests, which are largely GPU-bound, as one would expect. The differences here are inconsequential. The E6750 does make up some ground in 3DMark’s CPU tests, but not enough to put it ahead of the E6700.

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.

The E6750 splits these image processing tests with its predecessor, scoring slightly higher in picCOLOR but falling short when stitching together a panoramic photo.

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.

Moving to a 1333MHz bus grants no advantage whatsoever when encoding MP3s in LAME, but it does shave about 10 seconds off of our video encoding task.

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.

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.

Contrary to my expectations, the E6750 proves to have an advantage over the E6700 in these rendering applications. We’re still not seeing big performance gains, but these are gains.

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.

STARS Euler3d computational fluid dynamics
Charles O’Neill works in the Computational Aeroservoelasticity Laboratory at Oklahoma State University, and he contacted us 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.

The E6750’s slight but consistent advantage over the E6700 remains, well, consistent.

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.

As ever, the processors based on Intel’s Core microarchitecture excel here thanks to their ability to execute 128-bit SSE instructions in a single cycle. The E6750 doesn’t gain much from its faster bus, though.

Power consumption and efficiency
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, though. I’ve also 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.

Our Core 2 Duo E6750 test system is at something of a disadvantage here, because its Asus P5K Deluxe motherboard appears to consume more power at idle (and presumably also under load) than the most 975X boards, including the Intel D975XBX2 board on which we tested the other Core 2 processors. The E6750’s idle power draw is also higher because of a limitation of the processor. Like most Core 2 processors, the E6750’s minimum clock multiplier is 6X. In most Core 2 chips with a base FSB clock of 266MHz, that means the CPU’s lowest speed when throttled via SpeedStep or C1E halt is 1.6GHz. In the E6750, the 6X multiplier works out to a minimum idle clock of 2GHz. The E6750’s higher minimum clock will limit the effectiveness of power-saving schemes like SpeedStep.

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.

The Core 2 Duo E6700’s power draw jumps by 45W when going from idle to rendering. The E6750’s delta between idle and load is only 27W—quite a bit less. 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 E6750 system’s higher idle power draw hurts it here, as expected. 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.

Even with the handicaps, the E6750 remains relatively efficient, well head of any dual-core Athlon 64 and miles apart from what may be its most direct competitor, the Athlon 64 X2 6000+.

Overclocking
I started my overclocking exploits with an attempt to see how far I could push the E6750’s front-side bus speed, not its core clock. In our review of the P35 Express chipset, Geoff found that he hit a wall at about 490MHz (or 1960MHz, quad-pumped) and wondered whether it was his CPU or the chipset limiting the clock speed. That is, of course, a nice boost over the base FSB clock of 333MHz regardless, but I wanted to find out if I could take things further with the E6750. Turns out I hit the exact same wall. I lowered the E6750’s multiplier to 6X and was able to achieve a 490MHz bus speed with all-stock voltages. The system would not POST, though, with a 500MHz FSB. I tried raising the CPU, north bridge, and FSB termination voltages in the P5K Deluxe’s BIOS, but nothing helped. This motherboard—and perhaps the P35 north bridge—seems to have a ceiling of about 490MHz.

Those of you paying close attention may have realized that a CPU at a 6X multiplier on a 490MHz bus will be doing a very healthy 2.94GHz—and as I said, our E6750 hit that speed at its stock voltage. That was only the beginning, though. After an epic, trial-and-error iterative process, I finally decided that the max stable clock speed for this E6750 is 3.64GHz, nearly a full gigahertz higher than stock. That’s with a core voltage of 1.3875V and nothing fancier than regular old air cooling.

Throwing more voltage at the problem didn’t produce any higher stable clock frequencies. I was able to get the CPU to POST and boot into Windows at up to 3.76GHz with 1.425V, but the system would crash pretty quickly after I kicked off any sort of CPU-intensive task. In fact, I had to switch from a stock Intel cooler to slightly beefier model in order to extract the last 40MHz from the E6750. With the stock cooler, the system wasn’t 100% stable unless you dropped down to 3.6GHz.

But those are niggling details. We still got a near-1GHz overclock out of this thing, and we didn’t have to resort to crazy-high voltages or heroic cooling measures in order to make it happen. That’s a heckuva nice overclock from a relatively high speed grade CPU, and happily, its higher base FSB speed didn’t get in the way; we still had a little bit of room left before hitting the motherboard’s apparent bus speed ceiling.

Here’s a quick look at performance with the E6750 clocked up to 3.64GHz.

At this speed, the E6750 is the fastest dual-core processor we’ve ever seen.

Conclusions
Our tests results have shown us, pretty well conclusively, that the Core 2 Duo E6750’s faster front-side bus only offers minor, incremental performance gains over its E6700 predecessor. That’s not entirely bad news. The E6750 is still much faster than any dual-core CPU from AMD, and we’ve learned that current Core 2 Duo processors aren’t really hitting a bus bottleneck. That revelation may seem counterintuitive to those of us who watched the Pentium 4 post great gains in performance from nearly every bus speed bump it received, but the Core 2 is much more efficient in its use of bus and memory bandwidth than the Pentium 4 and its offshoots were. That’s one reason Intel can get away with packaging two Core 2 chips together in a single socket for quad-core action—there’s room on the bus for both of ’em. That’s not to say the 1333MHz front-side bus won’t have its uses. The most obvious candidates to benefit from the 1333MHz bus are those very same quad-core processors. In fact, Xeons have been using a 1333MHz bus for quite some time now, with great success. Also, our E6750’s ample overclocking headroom suggests Intel could introduce much higher speed grades of the Core 2 Duo if so desired, and those chips could likely use the extra bandwidth—especially with fast DDR3 memory coming into its own. Further down the road, Intel plans to pack 6MB of L2 cache into its 45nm processors, which works out to 12MB of total L2 cache on a dual-chip package. Those caches will have to be fed.

Unfortunately, most of those uses don’t apply to the E6750. Then again, there’s no major penalty to adopting this new bus speed baseline, either. The E6750’s one weakness here is its inability to drop its multiplier below 6X. That’s a bit of a step backward on the idle power efficiency front. I’d like to see Intel move to more aggressive lower multipliers like AMD has with Cool’n’Quiet, if possible. That’s a minor concern, though, in the grand scheme, and the move to a faster bus only solidifies the Core 2’s grip on the CPU performance crown.

Comments closed
    • monitor
    • 14 years ago

    I’m in total agreement with everything you’ve said. I’m thinking this is perhaps why we’re not seeing Intel release 3.6 Ghz cores. Maybe the cpu clock doubling the fsb clock is the “sweet” spot that keeps work per cycle efficiency high and power consumption low. Perhaps running the cpu at nearly 3 times the fsb speed introduces some wait states to RAM that do not exist in running the clock a 2x the FSB.
    I don’t know much of either benchmark, but I’d suspect the Valve test is much more sensitive to memory latency than the rendering which seems to care more about memory bandwidth available to the cores and the core clockspeed.

    • monitor
    • 14 years ago

    First post…not sure how the chart will look.
    New Original Change %
    E6750 Clockspeed 3.64Ghz 2.66Ghz 0.98 37% Increase
    Rendering 1157 875 282 32% Increase
    Valve particle 53 48 5 10% Increase
    New Original Change %
    X2 4400 Clockspeed 2.6Ghz 2.3Ghz 0.3 13% Increase
    Rendering 795 708 87 12% Increase
    Valve particle 28.7 24.3 4.4 18% Increase
    This may be just me thinking outloud but I’m not seeing a lot of bang out of the extra Ghz. I mean the E6750 gets 37% increase in clock and gets 32% increase (descent) in Rendering, but only 10% increase (blows) on Valve test. The X2 65nm series get 12% (Rendering)/18% (Valve) out of a 13% increase in clock. That seems to me to be outstanding. The 2.6Ghz results are taken from the X2 5000+ in place of an actual overclock, but the two are brisbane cores if I’m not mistaken. It seem the Intel chips are not scaling with clock as well as the AMD chips.

    Monitor

      • evermore
      • 14 years ago

      Presumably the X2’s also got a bump in memory speed with the extra CPU speed, so this may affect it.

      The Valve tests are confusing (given that I rarely look at the graphs in reviews so I don’t know exactly what it normally looks like) but the E4300 actually beat an E6400, which only tied with an E6300. Perhaps that’s an indicator that the latency is a very important issue with that test, since the 800MHz bus would be perfectly synced with the 800MHz memory, while a 1066MHz bus would be slightly off. This could also account for why an X2 gets a higher performance boost from higher clock speed.

      There are some other scores that seem backward, but the FX-70 also beat out the FX-72, which I assume had a lower than standard memory speed due to the underclocking, which would also point towards the memory being a major factor. The 90nm 5000+ also beat the 65nm, which makes sense due to the higher cache latency with Brisbane.

      The performance increases in Rendering scale nicely with the clock speeds in both series, so obviously in that test pure CPU speed is far more important than memory.

      I may be totally wrong, but at least it seems to explain it. The fact that the X2 4400 isn’t actually a 4400 would seem to explain a lot, depending on whether the underclocking affected memory speed. The inter-relatedness of the Athlon CPU with memory and other subsystems makes it less accurate to simulate different speeds.

      It’s long been known, and by design, that the integrated memory controller makes certain tasks perform differently with the Athlon 64 than a similar Intel chip would perform with an off-chip controller. It just means that tasks which benefit from low memory latency and high bandwidth will show a greater benefit with higher CPU speeds.

    • albundy
    • 14 years ago

    heh, those memory latencies are all that still score for AMD. But whats interesting is the gaming FPS. Its virtually a tie. looks like the GPU is doing its job.

    • MadManOriginal
    • 14 years ago

    I believe all the 1333FSB chips are the new ‘G0’ stepping which reduces TDP, at least on quad cores. The guys at xtremesystems.org have gotten very good results from early samples as well at lower volts than older C2Ds. It’s nice to see Intel is still making improvements in the 65nm process which has been in use for quite a while.

    Now Damage, please do some oc’ing with a hefty aftermarket aircooler! ๐Ÿ™‚ (You didn’t specify what you used on the overclocking page for the better cooling.)

    • DarkUltra
    • 14 years ago

    GeForce 7900 GTX? Are we sure we aren’t Vertex Shader or ROP limited here? Remember, fillrate scales much easier then geometry, new cards score higher in old and current games if there are many pixel shaders. Therefore NVIDIA and ATI have skimped on that part, until Microsoft said *[http://jooh.no/root/omg_3dcards/G80/Vertex_Shader_processing_limit.png<]ยง

    • Ricardo Dawkins
    • 14 years ago

    ban axe…baby !! ๐Ÿ˜€

    • Anomymous Gerbil
    • 14 years ago

    y[

      • Firestarter
      • 14 years ago

      that’s the “Quad-FX” platform, with 4 cores

      • Peldor
      • 14 years ago

      y[

        • Anomymous Gerbil
        • 14 years ago

        So.. the FX-7x chips can b[

          • accord1999
          • 14 years ago

          You could purchase a Quad FX MB and populate it with Quad FX CPU, but those scores are from a fully populated Quad FX system.

            • Anomymous Gerbil
            • 14 years ago

            OK, thanks. Maybe the comment in the review just needed a little clarification.

      • coldpower27
      • 14 years ago

      an Athlon FX-74 is just a Athlon 64×2 6000+ that is capable of working in Dual Processor motherboards, and hence as a Dual Core processor no faster then the 6000+. But I would think that E6750 isn’t the fastest Dual Core you guys have seen, as you have seen the X6800.

    • Nelliesboo
    • 14 years ago

    It’s nice they are putting out new stuff, but from a company stand point they should just milk what they have. No point if AMD can’t do anything to push you. “Make that money”.

      • leor
      • 14 years ago

      that’s exactly what they’re doing isn’t it? it’s pretty clear they can release 3.4ghz parts if they wanted to, but they’re keeping that in their pocket until they need it.

        • Calum
        • 14 years ago

        The new FSB is only so these chips will work with the new chipsets. Otherwise these are basically the same chips as were released last summer – albeit with probably a little more headroom due to ongoing process tweaks. The fact that so many people are already running FSBs in excess of the new higher one is strong evidence of this.

        Pretty impressive that even a year on Intel is still the performance king, especially when power is factored in as well….

          • Krogoth
          • 14 years ago

          Nope, these chips can work with any chipset that supports C2D. The VRM standards are still the same. The only catch is that you need to overclock the older chipsets to handle 1333Mhz FSB. P965 and Nforce i6xx series can do without breaking a sweat or the need for more juice.

            • flip-mode
            • 14 years ago

            So you can plop a 6750 into a p965 mobo and it’ll just run at 8*266 instead of 8*333?

            • Krogoth
            • 14 years ago

            Yep, it does the same thing as 266Mhz Socket A Thunderbirds did under older Socket A 200Mhz boards. ๐Ÿ˜‰

            • flip-mode
            • 14 years ago

            It’d be nice if the chip could recognize the max FSB of the mobo it was being plugged into and adjust it’s multiplier accordingly…

            • Krogoth
            • 14 years ago

            I doubt that since all non-EE C2Ds are half-locked.

            The only immediate problem that I can think from trying to place a 1333Mhz C2D into a older 1066Mhz board is that the BIOS is going say “Unknown CPU@ x speed” and might not use the correct voltage. The problem can obviously be fixed by a BIOS update.

            • Forge
            • 14 years ago

            Nah, cause then industrious hax0rs everywhere will tape/glue/cut/solder pins to make the CPU think it’s on a 266/200/whatever mobo when it’s still running 333 or more.

            That’s been done.

            • Forge
            • 14 years ago

            Actually, Nvidia’s 680i, at least, is officially rated for 1333 FSB already.

            Much like how the nForce2 was designed originall as 100/133 FSB and got 166 FSB officially added with a manual reprint, and 200/400 FSB solidified with a minor silicon respin, 680i is 200(800)/266(1066)/333(1333)FSB ready out of the box, and I’ve heard nVidia plans to refresh with an official 400(1600)FSB version in the not-too-distant future.

        • Nelliesboo
        • 14 years ago

        I wouldn’t even put out a faster fsb or newer chipset. I would sit on everything until amd pushed me to make something better. I would still have newer tech ready, but it would not come out until needed.

          • bhtooefr
          • 14 years ago

          I think they’re just trying to demoralize AMD at this point…

            • evermore
            • 14 years ago

            They should release a new speed grade every 2 weeks or so, maybe an extra 500MHz every month. And just keep going past 4GHz with it. AMD might just start crying and begging “c’mon, please, just give us a few minutes!”

          • coldpower27
          • 14 years ago

          There comes a point where you have to release something just to prevent stagnation. Intel releases new chipsets yearly give or take, it part of their money making strategy.

    • Calum
    • 14 years ago

    Hmmm. Given the stellar overclocking of the first wave of C2Ds, is anyone in this crowd really going to upgrade say, a P965 board for one of these? I have an E6400 running at an easy 3.2Ghz on a 1600Mhz FSB and until I can get something that really blows this thing out of the water, I don’t see myself upgrading anytime soon. That said, if you’re coming from eg any kind of P4 or an older single core Athlon64 this is a really nice leap in performance.

    It’s also fairly apparent that Intel is “coasting” as someone else said – from the O/C results it’s obvious these latest C2Ds have plenty of headroom and that Intel could be releasing faster speed grades if they were feeling the pressure from AMD. Since striking the “killer blow” last summer it’s as if Intel are just sitting back with their arms folded saying “come and have a go if you think you’re hard enough”. Intel released their best microarchitecture in ages when they were getting their backsides kicked (performance-wise) by AMD and I just don’t see where the next lot of impetus for performance improvement is going to come from ๐Ÿ™

      • [+Duracell-]
      • 14 years ago

      I don’t think it would be a good time to upgrade. I think most people by now will either just stick with what they have or wait for Penryn.

      At least, that’s what I would do. There’s no reason to upgrade, even if you’re using an older dual-core from AMD or Intel. Phenom and Penryn are around the corner, and at least one of those will be better than the current refresh.

      And I just upgraded to an E6320 haha. Next upgrade will be the video card, anyways.

    • blastdoor
    • 14 years ago

    It really is amazing how the A64 X2’s huge lead in memory bandwidth doesn’t seem to matter one little bit on the benchmarks. Historically, the worry was always that processor speed increases would quickly outpace memory bandwidth. Yet that doesn’t appear to have happened at all — if anything, the opposite appears to be the case — we have more memory bandwidth than we can use.

      • IntelMole
      • 14 years ago

      I dare say the situation is a bit more complicated than that.

      Athlons in general have historically been *[

        • flip-mode
        • 14 years ago

        Whilst the word “whilst” is in vogue of late, it has become not only overused, but misused (misused in this very sentence for example, which should have been started with “While”). I believe that you have in fact misused it. You said:

        y[

          • Fighterpilot
          • 14 years ago

          Wow two more killer posts from Flipmode…
          The first a”yaawwwn” then a grammar lesson and some snooty remark on how boring it all is….why do you even bother posting?
          So everyone can marvel at how you pwn a new review?
          Go away Mr Boring.Theres’ others here that like a new Damage review.
          ps you pwned yourself…have another go at “essentially”

            • Damage
            • 14 years ago

            Ok, enough. This stops here, or bans ensue.

            • Anomymous Gerbil
            • 14 years ago

            You’d actually ban people for irrelevant discussion?

          • IntelMole
          • 14 years ago

          I probably should have phrased it like that. Thank you for pointing out my ignorance.

          I will never, NEVER, EVER, phrase something so poorly again.

            • flip-mode
            • 14 years ago

            IM, I was just messing around and sent you a PM saying as much because I don’t want it to be construed any other way. Damage too. I got no replies.

      • Krogoth
      • 14 years ago

      Tight latencies and excessive bandwidth have very little impact on performance due to the fact that modern x86 CPUs have larger caches, advanced core logic tricks which negate most of the potential benefits of tighter latencies or a high amount of memory bandwidth.

        • flip-mode
        • 14 years ago

        It’s still nice to see Intel advance the platform, but just unfortunate that it doesn’t do a darn thing for ya. The good news is that we can all largely thumb our noses at DDR3 until it’s priced better than DDR2. Yay.

        • swaaye
        • 14 years ago

        Intel is /[http://realworldtech.com/page.cfm?ArticleID=RWT051607033728&p=7<]ยง

    • gbcrush
    • 14 years ago

    So in one way, Intel is raising prices for the same multiplier? Not trying to hate (good article, btw) just want to throw this out and get your feedback:

    See I couldn’t help noticing something. I’ve been planning my C2D build with an E6420 on that P5K deluxe.

    That’s an 8x multiplier, if taken to the 333FSB, resulting in the same 2.66Ghz rating as this E6750. I’m wondering how large that rumored July 22 price cut will be.

    Granted, maybe the E6750 has better OC headroom than the 6420. I wouldn’t doubt if a die srhink improves stability, but in a year’s time when the the old C2Ds are off the market and you want to buy something in the old E6400’s price bracket, you’ll end up getting a 6x multiplier instead of the the 8x .

    I guess I’m also saying it wouldnt surprise me if Intel were making a little bit more dough by taking the 6400 binned silicon with more headroom and turning them into 6750 price-ranged chips.

    • Dposcorp
    • 14 years ago

    Nice review.
    Price will have a lot to do with who purchases this.
    If the Intel and AMD Quad core parts start dropping below the $300 mark, some of us might forsake the speed for more cores.

    Thanks for the time though.

    • SuperSpy
    • 14 years ago

    EDIT: D’oh wrong article!

    • herothezero
    • 14 years ago

    Great article.

    However, it’s reviews like this that remove any reason for me to upgrade my two-year old X2 +3800 system; it just doesn’t seem to make much difference in my daily applications and gaming–not nearly as much as when I dropped an 8800GTX in the system.

    • flip-mode
    • 14 years ago

    So… essetially… yawwwwn

    • pedro
    • 14 years ago

    Intel is just coasting these days. In my opinion it’s good to see. Much easier to make good decisions as a company when you’re moving comfortably.

    • gratuitous
    • 14 years ago
      • evermore
      • 14 years ago

      No no. Yellow racing stripes. Or maybe flames (although with the P4 history, maybe not that).

      I don’t get why the magic marker indicates we haven’t evolved into Borg yet though. Or what the Harkonnen have in common with the Borg.

      Way off topic, I was thinking about changing my last name to Harkonnen. But that’s too many n’s to write in cursive.

        • soccergenius
        • 14 years ago

        Don’t forget the Type-R sticker, guaranteed to add 15hp!

    • IntelMole
    • 14 years ago

    Damn your conclusion. It took literally everything I had to say out of my mouth.

    Good review as always. It will be interesting to see if any gains are posted by 1333MHz quad-cores. They may get much closer to a linear increase in performance.

    • evermore
    • 14 years ago

    Tests should have been rerun (at least some of them) with the other chips on the Asus board. All the tests were largely invalidated in my eyes by using different platforms when you could have used the same one. You’ve ended up testing not the CPU, but the CPU/chipset combinations. The P35 was known to have better performance than the previous chipsets already, and the 975X is pretty much 2 generations behind it. There’s no telling whether the performance differences (when there were any) were due to the bus speed or the chipset.

    I know it saved a lot of time to just reuse old review numbers, but that can sometimes make for a less than complete review, lacking important information.

    In particular the power consumption comparisons could be vastly improved, since there’s such a difference between the power consumption of the chipsets. At the very least, running one new test with the E6700 on the Asus board would have been nice, so that you could directly compare whether the E6750 had any differences in power usage. You might have even run the E6700 with the higher bus but same clock speed, or as close as it would go, to show whether the difference in bus speed makes a difference compared to just the revision of the cores.

    The bits where the E6750 actually had lower performance than the E6700 are also glossed over a bit. No explanation is attempted. Why would graphics performance be particularly lower on the Asus board with the higher FSB, to the point that it affects scores? This is another point where using the same mainboard for comparison would have made a big difference.

    Still an interesting article, since it shows that when it’s introduced the lowered prices on the 1066 bus chips will make them a good value without sacrificing much performance.

      • Sargent Duck
      • 14 years ago

      While you make very valid points, of which I do agree, I don’t have a problem with Damage’s testing methods. The E6750 usually only beat the E6700 by a few frames (or less). Essentially, what I get from this review is that the D6750 is pretty much exactly the same. So it really doesn’t seem worth the extra time to re-test, as I can pretty much tell you what will happen with a E6750 on the older MB’s. Subtract 1 fps from each test.

        • Jigar
        • 14 years ago

        and what about the energy consumption.. ???

          • [+Duracell-]
          • 14 years ago

          It’ll consume a little less?

          • coldpower27
          • 14 years ago

          I really would like to see normalized energy comparisons, if your going to use the P35 chipset line from now on, test some of the older processors on there so we have a baseline, as of this point I can’t really tell how the E6750 and E6700 are in comparison to each other due to chipset differences on the power front.

          I would also love to see some of the new Celeron’s and Pentium Dual Core E21xx Series as well.

            • mboza
            • 14 years ago

            But fortunately someone decided to use a E6700 in the latest P35 motherboard round up, so we suddenly can compare E6700/P35 with these.

    • Krogoth
    • 14 years ago

    Beware that the 1333Mhz C2Ds have TXT a.k.a “Trustless Computing”.

    I always figured that 1333Mhz C2Ds were a marginable upgrade at best. It certainly took Intel a while to get them onto the market.

    I guess we will have to wait for Penyrn.

      • evermore
      • 14 years ago

      It didn’t “take them awhile” the way you seem to think it did. They didn’t NEED to get them into the market, the same as they haven’t needed to produce any faster speed grades. There was no need to bring them out and inevitably have to drop prices on the older ones. Much to my consternation.

      As for Trusted Computing: you need a TPM to have TC actually do anything.

      • d0g_p00p
      • 14 years ago

      You can turn it off in the BIOS.

        • Forge
        • 14 years ago

        No, you can’t. You’re thinking of the P3 serial number, Intel’s beta test into privacy violations.

          • gtoulouzas
          • 14 years ago

          Isn’t this the “La Grande” technology? When they were promoting it as such, intel had responded that end-users will be able to disable it at will.

    • Jive
    • 14 years ago

    Noticed a minor mistake on one of the benchmark graphs for Supreme Commander Simulation. The E6750 scored an 8887 while the QX6700 scored 8879, but the E6750 is in fourth place, and the QX6700 is in third.

    • BoBzeBuilder
    • 14 years ago

    Nothing beats reading reviews past midnight. I’ll go get a life now.

      • PrincipalSkinner
      • 14 years ago

      Drawing a finite state machine diagram beats reading reviews anytime. Just start downloading 120MB UML modeling software with 256kbs connection at 00:00 when you need to finish the diagram by morning.

        • Stijn
        • 14 years ago

        never mind, read something wrong ๐Ÿ˜‰

    • FireGryphon
    • 14 years ago

    Great article, as always.

    I’d like to see a couple of older CPUs in benchmarks. I’m always curious to see hoe processors a few generations old compare to newer procs, and how they do on the newest benchmarks.

    • danny e.
    • 14 years ago

    overclock looks nice. hope the price isnt any higher..
    Supreme Commander is not a very useful benchmark.

      • Krogoth
      • 14 years ago

      Damage is using version 3220 which is the retail release.

      I still don’t understand why he doesn’t uses version 3255 the latest build. :/

        • swaaye
        • 14 years ago

        probably cuz it would invalidate his collection of benchmark results from prior reviews.

          • Krogoth
          • 14 years ago

          Damage keep patching up Quake 3 and 4 in past reviews. He also updates system and graphical drivers ๐Ÿ˜‰

Pin It on Pinterest

Share This