The Nehalem Preview: Intel Does It Again
by Anand Lal Shimpi on June 5, 2008 12:05 AM EST- Posted in
- CPUs
A Quick Path to Memory
Our investigation begins with the most visibly changed part of Nehalem's architecture: the memory subsystem. Nehalem implements a very Phenom-like memory hierarchy consisting of small, fast individual L1 and L2 caches for each of its four cores and then a single, larger shared L3 cache feeding the entire chip.
Nehalem's L1 cache, despite being seemingly unchanged from Penryn, does grow in latency; it now takes 4 cycles to access vs. 3. The L2 cache is now only 256KB per core instead of being 24x the size in Penryn and thus can be accessed in only 11 cycles down from 15 (Penryn added an additional clock cycle over Conroe to access L2).
| CPU / CPU-Z Latency | L1 Cache | L2 Cache | L3 Cache |
| Nehalem (2.66GHz) | 4 cycles | 11 cycles | 39 cycles |
| Core 2 Quad Q9450 - Penryn - (2.66GHz) | 3 cycles | 15 cycles | N/A |
The L3 cache is quite possibly the most impressive, requiring only 39 cycles to access at 2.66GHz. The L3 cache is a very large 8MB cache, 4x the size of Phenom's L3, yet it can be accessed much faster. In our testing we found that Phenom's L3 cache takes a similar 43 cycles to access but at much lower clock speeds (2.0GHz). If we put these numbers into relative terms it takes 21.5 ns to get a request back from Phenom's L3 vs. 14.6 ns with Nehalem's - that's nearly 50% longer in Phenom.
While Intel did a lot of tinkering with Nehalem's caches, the inclusion of a multi-channel on-die DDR3 memory controller was the most apparent change. AMD has been using an integrated memory controller (IMC) since 2003 on its K8 based microprocessors and for years Intel has resisted doing the same, citing complexities in choosing what memory to support among other reasons for why it didn't follow in AMD's footsteps.
With clock speeds increasing and up to 8 cores (including GPUs) making their way into Nehalem based CPUs in the coming year, the time to narrow the memory gap is upon us. You can already tell that Nehalem was designed to mask the distance between the individual CPU cores and main memory with its cache design, and the IMC is a further extension of the philosophy.
The motherboard implementation of our 2.66GHz system needed some work so our memory bandwidth/latency numbers on it were way off (slower than Core 2), luckily we had another platform at our disposal running at 2.93GHz which was working perfectly. We turned to Everest Ultimate 4.50 to give us memory bandwidth and latency numbers from Nehalem.
Note that these figures are from a completely untuned motherboard and are using DDR3-1066 (dual-channel on the Core 2 system and triple-channel on the Nehalem system):
| CPU / Everest Ultimate 4.50 | Memory Read | Memory Write | Memory Copy | Memory Latency |
| Nehalem (2.93GHz) | 13.1 GB/s | 12.7 GB/s | 12.0 GB/s | 46.9 ns |
| Core 2 Extreme QX9650 - Penryn - (3.00GHz) | 7.6 GB/s | 7.1 GB/s | 6.9 GB/s | 66.7 ns |
Memory accesses on Conroe/Penryn were quick due to Intel's very aggressive prefetchers, memory accesses on Nehalem are just plain fast. Nehalem takes a little over 2/3 the time to complete a memory request as Penryn, and although we didn't have time to run comparable Phenom numbers I believe Nehalem's DDR3 memory controller is faster than Phenom's DDR2 controller.
Memory bandwidth is obviously greater with three DDR3 channels, Everest measured around a 70% increase in read bandwidth. While we don't have the memory bandwidth figures here, Gary measured a 10% difference in WinRAR performance (a test that's highly influenced by memory bandwidth and latency) between single-channel and triple-channel Nehalem configurations.
While we didn't really expect Intel to somehow do wrong with Nehalem's memory architecture, it's important to point out that it is very well implemented. Intel managed to change the cache structure and introduce an integrated memory controller while making both significantly faster than what AMD managed despite a four-year headstart.
In short: Nehalem can get data out of memory quick like bunnies.
Facebook
Twitter
RSS
108 Comments
View All Comments
Jedi2155 - Saturday, June 7, 2008 - link
Indeed, once the OEM's start demanding DDR3 for their system's due to Nehalem, we start seeing prices drop due economies of scale playing a greater part.RedFoxOne - Thursday, June 5, 2008 - link
I am still waiting for Intel and Google to merge so with their combined powers they can take over the world!JT
http://www.Ultimate-Anonymity.com">http://www.Ultimate-Anonymity.com
0g1 - Thursday, June 5, 2008 - link
Dude, wtf ... "Intel managed to change the cache structure and introduce an integrated memory controller while making both significantly faster than what AMD managed despite a four-year headstart."Thats bs. True, they are significantly faster, but you're comparing something that comes out in 6 months to something thats been out for like 1 year. And when it does come out (in 6 months) Shangai should be close by. Die shrink, cache increase, Hyper Transport clockspeed increase, lower latencies, and DDR3. Your comparison was simply unfair and untrue (considering AMD's upcoming cache and memory structure looks to be faster).
SiliconDoc - Monday, July 28, 2008 - link
Well, in this, one always likes the top dog better - they supply the goodies so much more often (even by unendorsed leaked channels which is GREAT if you ask me), and in turn the monetary stream from the resultant forces, whatever they may be.Add in the hype, and someone always has a favorite, so there ya go.
However, I find at least myself disappointed, since I don't have a grand every month to blow on new parts.
I am over and over again just not impressed, single core HT still has a really good hold on everything ( the D805 is crisys friendly for sure), and the latest videocard wars have hammered through so many tiny jumps - over such a long period and massive price restructuring... I'm sure glad I've waited.. I keep setting up the purchase then some new chip hits... the timing is very difficult the last 8 months.
This one appears to be another so what...again.
If you keep adding 5% to 15% to wowzie 25%, three or four or five times in a row, you finally get to something that isn't disappointing.
IMO they keep dribbling it out to us - maybe that's all they can do(OK I just LIED trying to be nice tothem), but they certainly spend an inordinate amount of time making 10 or 20 different "flavors" of all the chips, then they lock multipliers and disable catches...
I agree with the guy who said maybe he'll get an E8400 when they're 50 bucks. I'm not running a University server / research cruncher / consulting firm system.
Anyway good luck to AMD. Their Dx4/100 sample was exciting, as was their K6, good on their Thunderbird and Barton, no problem.
They do it too now though, "unlock" their chips for $$$$.
So, the whole system holds back FAST, and lays down SLOW to "saturate price point markets" and get everyone blowing their $$$ for some peice of hacked down crud. That's the way it IS.
HexiumVII - Thursday, June 5, 2008 - link
While AMD might not have a competitor anytime soon, lucky for us, Nvidia decided to go all ape bananas on Intel. General processors are really at a plateau for consumers. We really don't need 8 cores. What we do need is focused cores for Video and 3D. We are still pretty far from some really nice multimedia acceleration to finally kill our clunky mouse interface.0g1 - Friday, June 6, 2008 - link
We need all the cores we can get in CPU's. In the future, games are going to be multithreaded to the point of hundreds of threads.Focused cores for 3D should be a separate entity from the CPU die for maximum speed because:
1. Main memory speed is too slow compared to graphics memory.
2. 3D can be separated with little to no penalty, thus allowing you to get theoretically twice the speed via two processors (one for 3d and one for general computation).
mkruer - Thursday, June 5, 2008 - link
Compare the blue and yellow graph to Anand's two graphs. According to these benchmarks, "old" Penryn beats "new" Penryn by about 38% in single-threaded Cinebench and 17% in multi-threaded Cinebench.http://images.anandtech.com/graphs/nehalempreview_...">http://images.anandtech.com/graphs/nehalempreview_...
http://images.anandtech.com/graphs/nehalempreview_...">http://images.anandtech.com/graphs/nehalempreview_...
http://images.anandtech.com/graphs/amd%20phenom%20...">http://images.anandtech.com/graphs/amd%20phenom%20...
http://www.anandtech.com/printarticle.aspx?i=3153">http://www.anandtech.com/printarticle.aspx?i=3153
A mature Penryn system should score closer to the 3000 mark then what Anand listed.
You can look at other review sites as well
http://www.hardwarezone.com.my/articles/view.php?i...">http://www.hardwarezone.com.my/articles/view.php?i...
http://www.overclockersclub.com/reviews/intel_q945...">http://www.overclockersclub.com/reviews/intel_q945...
This should be raising some red flags people
Anand Lal Shimpi - Thursday, June 5, 2008 - link
That's a very good question, the Penryn system we ran the new numbers on is obviously different from the older systems but I'm trying to figure out now if there is a software explanation for why Cinebench is a lot slower now.The POV-Ray scores line up with what they were in our previous reviews, the only thing I can think of off the top of my head is that we've since switched to Vista SP1 and that has caused some problems where performance has gone down (see the 3dsmax scores).
I'm digging on the Cinebench question right now and will post back as soon as I have some more data.
-A
Anand Lal Shimpi - Thursday, June 5, 2008 - link
Just a quick check of the multithreaded numbers shows that the old and new Penryn numbers are where they should be, within 2%, so that's not an issue.Re-running the single threaded stuff now to see where we're at. Neither of the sites you pointed at used Vista SP1 either (including our older Phenom results), I may to run a quick install of Vista without SP1 to figure this one out.
I'll keep you posted.
-A
Anand Lal Shimpi - Thursday, June 5, 2008 - link
Fixed.That was entirely an error on my part, it wasn't a SP1 or a configuration issue. It was an Excel spreadsheet malfunction :) I used data from the wrong column (first run data vs. average run data) for Cinebench. Everything else looks to be exactly where it should be but I'll make another run through the spreadsheet to make sure.
I just reran the numbers to confirm and now things make much more sense. Not only are our XCPU scores virtually identical to what they were for the Phenom article, but the single threaded tests make a lot more sense. Furthermore, the scaling from 1 to n-threads makes a lot more sense now too. Penryn gets a 3.56x speedup from multithreading while Nehalem gets a 4.18x speedup - the difference in scaling partially being due to HT.
Thanks for bringing this to my attention and sorry for the mixup.
Take care,
Anand