Intel's Core 2 Extreme & Core 2 Duo: The Empire Strikes Back
by Anand Lal Shimpi on July 14, 2006 12:00 AM EST- Posted in
- CPUs
The architecture is called Core, processor family is Core 2, the product names are Core 2 Duo and Core 2 Extreme. In the past we've talked about its architecture and even previewed its performance, but today is the real deal. We've all been waiting for this day, the day Intel lifts the last remaining curtain on the chip that is designed to re-take the performance crown from AMD, to return Intel to its days of glory.
It sure looks innocent enough:
Core 2 Duo (left) vs. Pentium D (right)
What you see above appears to be no different than a Pentium D. Honestly, unless you flip it over there's no indication of what lies beneath that dull aluminum heat spreader.
Core 2 Duo (left) vs. Pentium D (right)
But make no mistake, what you see before you is not the power hungry, poor performing, non-competitive garbage (sorry guys, it's the truth) that Intel has been shoving down our throats for the greater part of the past 5 years. No, you're instead looking at the most impressive piece of silicon the world has ever seen - and the fastest desktop processor we've ever tested. What you're looking at is Conroe and today is its birthday.
Intel's Core 2 launch lineup is fairly well rounded as you can see from the table below:
| CPU | Clock Speed | L2 Cache |
| Intel Core 2 Extreme X6800 | 2.93GHz | 4MB |
| Intel Core 2 Duo E6700 | 2.66GHz | 4MB |
| Intel Core 2 Duo E6600 | 2.40GHz | 4MB |
| Intel Core 2 Duo E6400 | 2.13GHz | 2MB |
| Intel Core 2 Duo E6300 | 1.86GHz | 2MB |
As the name implies, all Core 2 Duo CPUs are dual core as is the Core 2 Extreme. Hyper Threading is not supported on any Core 2 CPU currently on Intel's roadmaps, although a similar feature may eventually make its debut in later CPUs. All of the CPUs launching today also support Intel's Virtualization Technology (VT), run on a 1066MHz FSB and are built using 65nm transistors.
The table above features all of the Core 2 processors Intel will be releasing this year. In early next year Intel will also introduce the E4200, which will be a 1.60GHz part with only a 800MHz FSB, a 2MB cache and no VT support. The E4200 will remain a dual core part, as single core Core 2 processors won't debut until late next year. On the opposite end of the spectrum Intel will also introduce Kentsfield in Q1 next year, which will be a Core 2 Extreme branded quad core CPU from Intel.
Core 2 Extreme vs. Core 2 Duo
Previously Intel had differentiated its "Extreme" line of processors by giving them larger caches, a faster FSB, Hyper Threading support, and/or higher clock speeds. With the Core 2 processor family, the Extreme version gets a higher clock speed (2.93GHz vs. 2.66GHz) and this time around it also gets an unlocked multiplier. Intel officially describes this feature as the following:
Core 2 Extreme is not truly "unlocked". Officially (per the BIOS Writers Guide), it is "a frequency limited processor with additional support for ratio overrides higher than the maximum Intel-tested bus-to-core ratio." Currently, that max tested ratio is 11:1 (aka 2.93G @ 1066 FSB). The min ratio is 6:1. However, do note that the Core 2 Extreme will boot at 2.93G unlike prior generation XE processors which booted to the lowest possible ratio and had to be "cranked up" to the performance ratio.
In other words, you can adjust the clock multiplier higher or lower than 11.0x, which hasn't been possible on a retail Intel chip for several years. By shipping the Core 2 Extreme unlocked, Intel has taken yet another page from AMD's Guide to Processor Success. Unfortunately for AMD, this wasn't the only page Intel took.
Manufacturing Comparison
The new Core 2 processors, regardless of L2 cache size, are made up of 291 million transistors on a 143 mm^2 die. This makes the new chips smaller and cheaper to make than Intel's Pentium D 900 series. The new Core 2 processors are also much smaller than the Athlon 64 X2s despite packing more transistors thanks to being built on a 65nm process vs. 90nm for the X2s.
| CPU | Manufacturing Process | Transistor Count | Die Size |
| AMD Athlon 64 X2 (2x512KB) | 90nm | 154M | 183 mm^2 |
| Intel Core 2 | 65nm | 291M | 143 mm^2 |
| Intel Pentium D 900 | 65nm | 376M | 162 mm^2 |
Intel's smaller die and greater number of manufacturing facilities results in greater flexibility with pricing than AMD.
Facebook
Twitter
RSS
202 Comments
View All Comments
code255 - Friday, July 14, 2006 - link
Thanks a lot for the Rise of Legends benchmark! I play the game, and I was really interested in seeing how different CPUs perform in it.And GAWD DAMN the Core 2 totally owns in RoL, and that's only in a timedemo playback environment. Imagine how much better it'll be over AMD in single-player games where lots of AI calculations need to be done, and when the settings are at max; the high-quality physics settings are very CPU intensive...
I've so gotta get a Core 2 when they come out!
Locutus465 - Friday, July 14, 2006 - link
It's good to see intel is back. Now hopefully we'll be seeing some real innovation in the CPU market again. I wonder what the picture is going to look like in a couple years when I'm ready to upgrade again!Spoonbender - Friday, July 14, 2006 - link
First, isn't it misleading to say "memory latency" is better than on AMD systems?What happens is that the actual latency for *memory* access is still (more or less) the same. But the huge cache + misc. clever tricks means you don't have to go all the way to memory as often.
Next up, what about 64-bit? Wouldn't it be relevant to see if Conroe's lead is as impressive in 64-bit? Or is it the same horrible implementation that Netburst used?
JarredWalton - Friday, July 14, 2006 - link
Actually, it's the "clever tricks" that are reducing latency. (Latency is generally calculated with very large data sets, so even if you have 8 or 16 MB of cache the program can still determine how fast the system memory is.) If the CPU can analyze RAM access requests in advance and queue up the request earlier, main memory has more time to get ready, thus reducing perceived latency from the CPU. It's a matter of using transistors to accomplish this vs. using them elsewhere.It may also be that current latency applications will need to be adjusted to properly compute latency on Core 2, but if their results are representative of how real world applications will perceive latency, it doesn't really matter. Right now, it appears that Core 2 is properly architected to deal with latency, bandwidth, etc. very well.
Spoonbender - Friday, July 14, 2006 - link
Well, when I think of latency, I think worst-case latency, when, for some reason, you need to access something that is still in memory, and haven't already been queued.Now, if their prefetching tricks can *always* start memory loads before they're needed, I'll agree, their effective latency is lower. But if it only works, say, 95% of the time, I'd still say their latency is however long it takes for me to issue a memory load request, and wait for it to get back, without a cache hit, and without the prefetch mechanism being able to kick in.
Just technical nitpicking, I suppose. I agree, the latency that applications will typcially perceive is what the graph shows. I just think it's misleading to call that "memory latency"
As you say, it's architected to hide the latency very well. Which is a damn good idea. But that's still not quite the same as reducing the latency, imo.
Calin - Friday, July 14, 2006 - link
You could find the real latency (or most of it) by reading random locations in the main memory. Even the 4MB cache on the Conroe won't be able to prefetch all the main memory.Anyway, the most interesting is what memory latency the application that run feels. This latency might be lower on high-load, high-memory server processors (not that current benchmarks hint at this for Opteron against server-level Core2)
JarredWalton - Friday, July 14, 2006 - link
"You could find the real latency (or most of it) by reading random locations in the main memory."I'm pretty sure that's how ScienceMark 2.0 calculates latency. You have to remember, even with the memory latency of approximately 35 ns, that delay means the CPU now has approximately 100 cycles to go and find other stuff to do. At an instruction fetch rate of 4 instructions per cycle, that's a lot of untapped power. So, while it waits on main memory access one, it can be scanning the next accesses that are likely to take place and start queuing them up. And the net result is that you may never actually be able to measure latency higher than about 35 ns or whatever.
The way I think of it is this: pipeline issues aside, a large portion of what allowed Athlon 64 to outperform at first was reduced memory latency. Remember, Pentium 4 was easily able to outperform Athlon XP in the majority of benchmarks -- it just did so at higher clock speeds. (Don't *even* try to tell me that the Athlon XP 3200+ was as fast as a Pentium 4 3.2 GHz... LOL.) AMD boosted performance by about 25% by adding an integrated memory controller. Now Intel is faster at similar clock speeds, and although the 4-wide architectural design helps, they almost certainly wouldn't be able to improve performance without improving memory latency -- not just, but in actual practice. With us, I have to think that our memory latency scores are generally representative of what applications see. All I can say is, nice design Intel!
JarredWalton - Friday, July 14, 2006 - link
"...allowed Athlon 64 to outperform at first was...."Should be:
"...allowed Athlon 64 to outperform NetBurst was..."
Bad Dragon NaturallySpeaking!
yacoub - Friday, July 14, 2006 - link
""Another way of looking at it is that Intel's Core 2 Duo E6600 is effectively a $316 FX-62".Then the only question that matters at all for those of us with AMD systems is: Can I get an FX-62 for $316 or less (and run it on my socket-939 board)? If so, I would pick one up. If not, I would go Intel.
End of story.
Gary Key - Friday, July 14, 2006 - link
A very good statement. :)