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
Gaming with Core 2 and CrossFire on 975X
We were so used to getting excited over AMD processor launches that we almost forgot what an important Intel CPU launch was like. You see, AMD and Intel behave very differently when at a dinner table preparing to eat their meals. AMD will eat when its partners eat; companies like ATI and NVIDIA get to share in the joy of a new AMD product launch as they are busy building chipsets for the new platform. That's why we get a new nForce chipset whenever AMD launches a new CPU. Intel on the other hand isn't as generous; Intel likes to eat first, and then whatever remains after it's nice and full can be scraped off the table and given to its partners. This is why today's launch is taking place pretty much exclusively on Intel chipsets, with retail products based on ATI/NVIDIA chipsets shipping in the coming months.
Intel's table manners aren't as nice as AMD's largely because they don't have to be. Intel has a lot more fabs than AMD, however they aren't all pumping out 65nm Core 2 Duos on 300mm wafers; instead many of them are still using old 90nm or 130nm process technology. It's not exactly economically feasible to keep converting all of the fabs to the latest technology as soon as it's available, so Intel uses up excess capacity in its older fabs by producing chipsets. AMD does not have this luxury so it depends on companies like ATI, NVIDIA, SiS and VIA for the platform side of things, and thus is much nicer at the dinner table.
Eating habits aside, what this means for us is that our only real options to test Core 2 Duo are with Intel chipsets. NVIDIA's nForce 590 SLI reference board for Core 2 Duo is in our labs but its BIOS isn't finalized yet so NVIDIA is asking us to hold off on using it for a couple more weeks. At the same time, we're hearing that we shouldn't expect any retail motherboards using ATI chipsets for Core 2 Duo motherboards until September at the earliest, once again leaving us with Intel.
Don't get us wrong; Intel chipsets are far from a terrible option. In fact, Intel continues to make extremely trouble-free platforms. It's not stability or performance that we're concerned about, as Intel has got both of those down pat. The issue however is multi-GPU compatibility.
You see, NVIDIA is a lot like Intel in that it wants to eat first or maybe, if the right people are at the table, at the same time as its partners. The problem with two companies that have identical eating habits is that no one ends up eating, and thus we have no SLI support on Intel chipsets. NVIDIA views this as an upper hand because honestly it's the only tangible advantage anyone has ever held over an Intel chipset since the days when Intel and Rambus were inseparable. If you want the best multi-GPU solution on the market you buy NVIDIA graphics cards, but they won't run (together) on Intel chipsets so you've got to buy the NVIDIA chipset as well - sounds like NVIDIA is trying to eat some of Intel's dinner, and this doesn't make Intel very happy.
Luckily for Intel, there's this little agreement it has with NVIDIA's chief competitor - ATI. Among other things, it makes sure that Intel platforms (or platform in this case, since it only officially works on the 975X) can support CrossFire, ATI's multi-GPU technology. Unfortunately, CrossFire isn't nearly as polished as NVIDIA's SLI. Case in point would be benchmarking for this Core 2 Duo article, which used a pair of X1900 XTs running in CrossFire mode. During our testing, CrossFire decided to disable itself after a simple reboot - twice. No warnings, no hardware changes, just lower frame rates after a reboot and a CrossFire enable checkbox that had become unchecked. Needless to say it was annoying, but by now we already know that CrossFire needs work and ATI is on it.
More than anything this is simply a message to ATI and Intel: if CrossFire had been in better shape, the high end gaming enthusiast could have been satisfied today, but instead they will have to wait a little longer for the first nForce 500 motherboards with Core 2 support to arrive (or settle for a nForce 4 board with Core 2 support).
Why does multi-GPU even matter? Given how fast Intel's Core 2 processors are, we needed to pair them with a GPU setup that was well matched - in this case we went with a pair of X1900 XTs running in CrossFire mode. With a pair of X1900 XTs we could run at 1600 x 1200 for all of our gaming tests, achieving a good balance between CPU and GPU loads and adequately characterizing the gaming performance of Intel's Core 2 line.
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. :)