The Sandy Bridge Preview
by Anand Lal Shimpi on August 27, 2010 2:38 PM ESTA New Architecture
This is a first. Usually when we go into these performance previews we’re aware of the architecture we’re reviewing, all we’re missing are the intimate details of how well it performs. This was the case for Conroe, Nehalem and Lynnfield (we sat Westmere out until final hardware was ready). Sandy Bridge, is a different story entirely.
Here’s what we do know.
Sandy Bridge is a 32nm CPU with an on-die GPU. While Clarkdale/Arrandale have a 45nm GPU on package, Sandy Bridge moves the GPU transistors on die. Not only is the GPU on die but it shares the L3 cache of the CPU.
There are two different GPU configurations, referred to internally as 1 core or 2 cores. A single GPU core in this case refers to 6 EUs, Intel’s graphics processor equivalent (NVIDIA would call them CUDA cores). Sandy Bridge will be offered in configurations with 6 or 12 EUs.
While the numbers may not sound like much, the Sandy Bridge GPU is significantly redesigned compared to what’s out currently. Intel already announced a ~2x performance improvement compared to Clarkdale/Arrandale, and I can say that after testing Sandy Bridge Intel has been able to achieve at least that.
Both the CPU and GPU on SB will be able to turbo independently of one another. If you’re playing a game that uses more GPU than CPU, the CPU may run at stock speed (or lower) and the GPU can use the additional thermal headroom to clock up. The same applies in reverse if you’re running something computationally intensive.
On the CPU side little is known about the execution pipeline. Sandy Bridge enables support for AVX instructions, just like Bulldozer. The CPU will also have dedicated hardware video transcoding hardware to fend off advances by GPUs in the transcoding space.
Caches remain mostly unchanged. The L1 cache is still 64KB (32KB instruction + 32KB data) and the L2 is still a low latency 256KB. I measured both as still 4 and 10 cycles respectively. The L3 cache has changed however.
Only the Core i7 2600 has an 8MB L3 cache, the 2400, 2500 and 2600 have a 6MB L3 and the 2100 has a 3MB L3. The L3 size should matter more with Sandy Bridge due to the fact that it’s shared by the GPU in those cases where the integrated graphics is active. I am a bit puzzled why Intel strayed from the steadfast 2MB L3 per core Nehalem’s lead architect wanted to commit to. I guess I’ll find out more from him at IDF :)
The other change appears to either be L3 cache latency or prefetcher aggressiveness, or both. Although most third party tools don’t accurately measure L3 latency they can usually give you a rough idea of latency changes between similar architectures. In this case I turned to cachemem which reported Sandy Bridge’s L3 latency as 26 cycles, down from ~35 in Lynnfield (Lynnfield’s actual L3 latency is 42 clocks).
As I mentioned before, I’m not sure whether this is the result of a lower latency L3 cache or more aggressive prefetchers, or both. I had limited time with the system and was unfortunately unable to do much more.
And that’s about it. I can fit everything I know about Sandy Bridge onto a single page and even then it’s not telling us much. We’ll certainly find out more at IDF next month. What I will say is this: Sandy Bridge is not a minor update. As you’ll soon see, the performance improvements the CPU will offer across the board will make most anyone want to upgrade.
200 Comments
View All Comments
tech6 - Friday, August 27, 2010 - link
More speed with less power - it looks like a very competitive product. I really hope that AMD has something up their sleeve with Bulldozer and Bobcat to compete with Sandy Bridge.killless - Friday, August 27, 2010 - link
17% higher performance is just not exciting.You need to give me 50% improvement at least to make me want to spend $1000 for new CPU/Motherboard/memory.
It really hasn't been all that exciting since Core 2 Quad...
tatertot - Friday, August 27, 2010 - link
I take it turbo was also disabled on the rest of the parts used to compare, right?Anand Lal Shimpi - Friday, August 27, 2010 - link
Turbo was enabled on everything else - SB performance should be higher for final parts.Take care,
Anand
tatertot - Friday, August 27, 2010 - link
Oh!Well that puts the IPC gains of Sandy over Westmere at something like 20% then, considering the 880 turbos up to 3.73GHz on single-threaded work.
That's pretty impressive.
Drag0nFire - Friday, August 27, 2010 - link
I just want to say first of all, this totally made my Friday! I love previews of upcoming architectures!Any news on the roadmap for the mobile variant of Sandy Bridge? Or do I have to wait til IDF?
Jamahl - Friday, August 27, 2010 - link
What system was this benchmarked on Anand?Anand Lal Shimpi - Friday, August 27, 2010 - link
Clarkdale - those charts were actually pulled from here, just with the SB numbers added:http://www.anandtech.com/show/2952/2
We didn't have the system for long enough to rerun the tests with the 5450 on the H67 board. The 5450 is GPU bound at those resolutions/settings however:
http://images.anandtech.com/graphs/5450_0203102236...
Those numbers were generated with a Core i7 920.
Take care,
Anand
Anand Lal Shimpi - Friday, August 27, 2010 - link
I just ran a sanity check on the Core i7 880 with the 5450, the numbers don't move by more than the normal test margins - the 5450 is totally GPU bound here.Take care,
Anand
ESetter - Friday, August 27, 2010 - link
Do you know if any of the benchmarks make use of AVX instructions? Sandy Bridge effectively doubles the maximum throughput for compute-intensive operations like SGEMM and DGEMM. While it might not translate to a 2x speedup in real-world applications, I imagine it should give a significant gain, at least in the HPC field.