Barcelona Architecture: AMD on the Counterattack
by Anand Lal Shimpi on March 1, 2007 12:05 AM EST- Posted in
- CPUs
Getting Spendy with Transistors - L3 cache
AMD lost the cache race to Intel long ago, but that's more of a result of manufacturing capacity than anything else. AMD knew it could not compete with Intel's ability to churn out more transistors on smaller processes faster, so it did the next best thing and integrated a memory controller. With the K8's on-die memory controller, AMD reduced the need for larger caches, which is why even current Athlon 64 X2s only have a 512KB L2 cache per core - a figure that Intel introduced back in 2002 with its Northwood core.
These days two Core 2 cores share up to 4MB of L2 cache, while the fastest offerings from AMD weigh in at half that. The gap will continue to widen with Barcelona, as each of its four cores will only have a 512KB L2 cache. While a quad-core Barcelona chip will have 2MB of total L2 cache for all four cores, a quad-core Kentsfield currently has 8MB of L2 cache for all four cores. By the end of this year, Intel's Penryn is expected to have 12MB of L2 cache for all of its cores.
In order to keep die sizes manageable, AMD constructed its quad-core Barcelona out of four cores each with a 128KB L1 and 512KB L2, much like most mainstream K8 based products today. However, the era of multithreaded applications demands that multi-core CPUs should have some common pool of high speed memory to keep them running at peak efficiency.
With four cores sharing a single die, AMD didn't want to complicate its design by introducing a large unified L2 cache. Instead, it took the K8 cache hierarchy and added a third level of cache to the mix - shared among all four cores. At 65nm, a quad-core Barcelona will have a 2MB L3 cache that is shared by all four cores.
The hierarchy in Barcelona works like this: the L2 caches are filled with victims from the L1 cache. When a cache gets full, data that was not recently used is evicted to make room for new data that the cache controller determines is good to keep in the cache. In a victim cache structure, the evicted data is placed in a storage area known as a victim cache instead of being removed from cache all together. If the data should become useful again, the cache controller simply has to fetch it from the victim cache rather than much slower main memory; victims from Barcelona's L1 are kicked out to the L2 cache.
The new L3 cache, acts as a victim for the L2 cache. So when the small L2 cache fills up, evicted data is sent to the larger L3 cache where it is kept until space is needed. The algorithms that govern the L3 cache's operation are designed to accommodate data that is likely to be needed by multiple cores. If the CPU fetches a bit of code, a copy is left in the L3 cache since the code is likely to be shared among the four cores. Pure data load requests however go through a separate process. The cache controller looks at history and if the data has been shared before, a copy will be left in the L3 cache; otherwise it will be invalidated.
Associativity hasn't been changed for the L1 and L2 caches; they are still 2-way and 16-way set associative, respectively. However, the new L3 cache is 32-way set associative. It has been designed to increase the hit rate of a relatively small cache compared to its competition.
AMD lost the cache race to Intel long ago, but that's more of a result of manufacturing capacity than anything else. AMD knew it could not compete with Intel's ability to churn out more transistors on smaller processes faster, so it did the next best thing and integrated a memory controller. With the K8's on-die memory controller, AMD reduced the need for larger caches, which is why even current Athlon 64 X2s only have a 512KB L2 cache per core - a figure that Intel introduced back in 2002 with its Northwood core.
These days two Core 2 cores share up to 4MB of L2 cache, while the fastest offerings from AMD weigh in at half that. The gap will continue to widen with Barcelona, as each of its four cores will only have a 512KB L2 cache. While a quad-core Barcelona chip will have 2MB of total L2 cache for all four cores, a quad-core Kentsfield currently has 8MB of L2 cache for all four cores. By the end of this year, Intel's Penryn is expected to have 12MB of L2 cache for all of its cores.
In order to keep die sizes manageable, AMD constructed its quad-core Barcelona out of four cores each with a 128KB L1 and 512KB L2, much like most mainstream K8 based products today. However, the era of multithreaded applications demands that multi-core CPUs should have some common pool of high speed memory to keep them running at peak efficiency.
With four cores sharing a single die, AMD didn't want to complicate its design by introducing a large unified L2 cache. Instead, it took the K8 cache hierarchy and added a third level of cache to the mix - shared among all four cores. At 65nm, a quad-core Barcelona will have a 2MB L3 cache that is shared by all four cores.
The hierarchy in Barcelona works like this: the L2 caches are filled with victims from the L1 cache. When a cache gets full, data that was not recently used is evicted to make room for new data that the cache controller determines is good to keep in the cache. In a victim cache structure, the evicted data is placed in a storage area known as a victim cache instead of being removed from cache all together. If the data should become useful again, the cache controller simply has to fetch it from the victim cache rather than much slower main memory; victims from Barcelona's L1 are kicked out to the L2 cache.
The new L3 cache, acts as a victim for the L2 cache. So when the small L2 cache fills up, evicted data is sent to the larger L3 cache where it is kept until space is needed. The algorithms that govern the L3 cache's operation are designed to accommodate data that is likely to be needed by multiple cores. If the CPU fetches a bit of code, a copy is left in the L3 cache since the code is likely to be shared among the four cores. Pure data load requests however go through a separate process. The cache controller looks at history and if the data has been shared before, a copy will be left in the L3 cache; otherwise it will be invalidated.
Associativity hasn't been changed for the L1 and L2 caches; they are still 2-way and 16-way set associative, respectively. However, the new L3 cache is 32-way set associative. It has been designed to increase the hit rate of a relatively small cache compared to its competition.
Facebook
Twitter
RSS
83 Comments
View All Comments
JarredWalton - Thursday, March 1, 2007 - link
Games have quite a lot of LOAD instructions, like most programs, as well as plenty of branches (esp. in the AI routines). Most likely the boost that Core 2 gets is due in a large part to the better instruction reordering and branch prediction, although the cache and prefetchers probably help as well. Given AMD was better than NetBurst due to memory latency, through in better OOE (Out of Order Execution) logic and keep the improved latency and they should do pretty well.Naturally, everything at this point is purely speculation, but in the next few months we should start to get a better idea of what's in store and how it will perform. One problem that still remains is that even if AMD can be competitive clock-for-clock, Intel looks primed to be able to go up to at least 3.6 GHz dual core and 3.46 GHz quad core if necessary. AMD has traditionally not reached clock speeds nearly as high as Intel, possibly due in part to having more metal layers (speculation again - process tech and other features naturally play a role), so if they release 2.9GHz Barcelona at $1000 you can pretty much guarantee Intel will launch 3.2 and/or 3.46 GHz Kentsfield (and/or FSB1333 3.33 GHz).
On the bright side, at least things should stay interesting in the CPU world. :D
yyrkoon - Thursday, March 1, 2007 - link
Yes, interresting indeed, but from experience, AMD has always been too vocal in what they plan on doing, especially during the times they are in a 'rut'.What this usually means to me, is that AMD is trying to blow smoke up our backsides, we'll see though.
Keep in mind, my main desktop system, and my backup server for that matter, both are AMD systems. The phrase "cost effective" applies here.
kilkennycat - Thursday, March 1, 2007 - link
Yesterday, Intel announced that they were converting a fourth fab to 45nm. A great deal of confidence in that process. And a few days ago they announced desktop shipments of Penryn-based CPUs pulled forward into 2007. Looks as if AMDs 'window of opportunity' is likely to be very small. IBM has not yet announced a successful implementation of a RAM on their 45nm process. Intel had their RAM design on 45nm up and running late 2005.archcommus - Thursday, March 1, 2007 - link
True but the move to 45 nm might not make a huge difference in real world performance, just like the move to 65 nm didn't for AMD. Their next full blown architecture will still be a ways off.Roy2001 - Thursday, March 1, 2007 - link
Dislike AMD's move to 65nm process, move to 45nm has shown that Penryn would eats less power and runs faster thanks to its high K material and metal gate.smitty3268 - Thursday, March 1, 2007 - link
Every process shows that in theory before chips are actually being made on it. We'll see what actually happens when Penryn is released, not before.chucky2 - Thursday, March 1, 2007 - link
Has AMD given any indication of how probable dropping an Agena or Kuma CPU into an existing AM2 motherboard will go?Especially AMD's own newly released 690G or the upcoming nVidia MCP68?
Chuck
mamisano - Thursday, March 1, 2007 - link
It has been stated in the past that AM2+ based products will run in AM2 based boards. The limitation, if I understand it correctly, will be the lack of support of the new power features.Someone correct me if I am wrong :)
chucky2 - Thursday, March 1, 2007 - link
Then it should be no problem for AMD to confirm through AnandTech that this is the case.Surely if Barcelona is this close to shipping (only a few months away), AMD must know if Agena and/or Kuma will work in current AM2 motherboards, especially their own 690 series their just about to release.
All I'm asking for is a definite either way, it shouldn't be that hard for AMD to do at this point.
Chuck
mino - Friday, March 2, 2007 - link
AMD stated PUBLICLY to anyone who listened that AM2+ stuff will plug into AM2, just BIOS update needed.Why should they react to any consumer who ask on some forum the same question every second week ?
Most important is they said it WILL(not "may") work with AM2-spec boards to big Tier 1 OEM's.
They can not make it incompatible therefore. They would be out of bussines in no time.