Barcelona Architecture: AMD on the Counterattack
by Anand Lal Shimpi on March 1, 2007 12:05 AM EST- Posted in
- CPUs
SSE128
Many of the "major" changes to Barcelona were driven by one significant change: what AMD is calling SSE128. In the K8 architecture AMD can execute two SSE operations in parallel; however the SSE execution units are only 64-bits wide. For 128-bit SSE operations, the K8 had to handle them as two 64-bit operations. This also means that when a 128-bit SSE instruction is fetched, it is first decoded into two micro-ops (one for each 64-bit half of the instruction), thus taking up an extra decode port for a single instruction.
Barcelona widens the execution units that handle SSE operations from 64-bits to 128-bits, so now 128-bit SSE operations don't have to be broken up into two 64-bit operations. This also means that you get more usable decode bandwidth since 128-bit SSE instructions now map to a single micro-op instead of two. The FP scheduler can now handle these 128-bit SSE operations as well.
It's the increase to SSE execution width that drove a number of other changes within the core. Since you effectively have more decode bandwidth when executing 128-bit SSE instructions AMD discovered a new bottleneck: instruction fetch bandwidth. These 128-bit SSE instructions tend to be quite large, and in order to maximize the number decoded in parallel the Barcelona core can now fetch 32-bytes per cycle, up from 16-bytes in K8. The 32B instruction fetch not only benefits SSE code but also seems to benefit integer code as well. Bigger instructions in general will see a performance boost here.
Now that you can fetch and decode more instructions, you need to be able to get more data to the execution core and thus AMD widened the interface between the L1 data cache and Barcelona's SSE registers. Barcelona can now perform two 128-bit SSE loads per cycle from the L1-D cache compared to two 64-bit loads per cycle in K8. AMD then widened the interface between the L2 cache and the memory controller so that now 128-bits can be transferred per cycle, once again to balance out all of the aforementioned changes.
The culmination of the SSE128 improvements is very similar to some of the changes made in the Yonah to Merom transition. Prior to Conroe/Merom, Yonah could not keep up with AMD's K8 when it came to FP/SSE performance. Almost a year and a half ago we did an article where we compared AMD's K8 to Intel's Yonah running at the same clock speed. While Yonah was able to equal the K8's performance in general applications, professional 3D rendering and games, it could not compete when it came to video encoding.
There were a number of SSE performance improvements made to Yonah but it wasn't until Intel's Core 2 processors that Intel was really able to outperform AMD in our video encoding tests. Whether the improvements were due to the single cycle SSE throughput introduced in Core 2 or the wider front end or a combination of both remains to be seen. Although it's difficult to compare specs between two very different architectures, encoding performance is a sore spot for AMD today, and it's something that the SSE128 changes can only help.
| AMD Architecture Comparison | ||
| K8 | Barcelona | |
| SSE Execution Width | 64-bit | 128-bit |
| Instruction Fetch Bandwidth | 16 bytes/cycle | 32 bytes/cycle |
| Data Cache Bandwidth | 2 x 64-bit loads/cycle | 2 x 128-bit loads/cycle |
| L2/Northbridge Bandwidth | 64 bits/cycle | 128 bits/cycle |
| FP Scheduler Depth | 36 Dedicated x 64-bit ops | 36 Dedicated x 128-bit ops |
Many of the "major" changes to Barcelona were driven by one significant change: what AMD is calling SSE128. In the K8 architecture AMD can execute two SSE operations in parallel; however the SSE execution units are only 64-bits wide. For 128-bit SSE operations, the K8 had to handle them as two 64-bit operations. This also means that when a 128-bit SSE instruction is fetched, it is first decoded into two micro-ops (one for each 64-bit half of the instruction), thus taking up an extra decode port for a single instruction.
Barcelona widens the execution units that handle SSE operations from 64-bits to 128-bits, so now 128-bit SSE operations don't have to be broken up into two 64-bit operations. This also means that you get more usable decode bandwidth since 128-bit SSE instructions now map to a single micro-op instead of two. The FP scheduler can now handle these 128-bit SSE operations as well.
It's the increase to SSE execution width that drove a number of other changes within the core. Since you effectively have more decode bandwidth when executing 128-bit SSE instructions AMD discovered a new bottleneck: instruction fetch bandwidth. These 128-bit SSE instructions tend to be quite large, and in order to maximize the number decoded in parallel the Barcelona core can now fetch 32-bytes per cycle, up from 16-bytes in K8. The 32B instruction fetch not only benefits SSE code but also seems to benefit integer code as well. Bigger instructions in general will see a performance boost here.
Now that you can fetch and decode more instructions, you need to be able to get more data to the execution core and thus AMD widened the interface between the L1 data cache and Barcelona's SSE registers. Barcelona can now perform two 128-bit SSE loads per cycle from the L1-D cache compared to two 64-bit loads per cycle in K8. AMD then widened the interface between the L2 cache and the memory controller so that now 128-bits can be transferred per cycle, once again to balance out all of the aforementioned changes.
The culmination of the SSE128 improvements is very similar to some of the changes made in the Yonah to Merom transition. Prior to Conroe/Merom, Yonah could not keep up with AMD's K8 when it came to FP/SSE performance. Almost a year and a half ago we did an article where we compared AMD's K8 to Intel's Yonah running at the same clock speed. While Yonah was able to equal the K8's performance in general applications, professional 3D rendering and games, it could not compete when it came to video encoding.
There were a number of SSE performance improvements made to Yonah but it wasn't until Intel's Core 2 processors that Intel was really able to outperform AMD in our video encoding tests. Whether the improvements were due to the single cycle SSE throughput introduced in Core 2 or the wider front end or a combination of both remains to be seen. Although it's difficult to compare specs between two very different architectures, encoding performance is a sore spot for AMD today, and it's something that the SSE128 changes can only help.
Facebook
Twitter
RSS
83 Comments
View All Comments
Amiteriver - Tuesday, March 27, 2007 - link
Sounds groooovyNow lets just hope they have something good to plug it into.
trisweb2 - Friday, March 16, 2007 - link
I just want to say how refreshing it is to read an article written by Anand. He is a master of the English language; he perfectly communicates and explains every technical detail and I come away with a better understanding of whatever he's talking about.Thank you, Anand, for being a good writer!
MrWizard6600 - Thursday, March 22, 2007 - link
I Agree, Outstanding.No other site I know of gives nearly as many in depth details, and while ill admit my knowlage of some of the terms is sketchy, I got through that one with a good understanding.
Sounds like AMD has something to fight Core 2 against.
I do have one criticism:
I would have loved to have heard what Intels equivilent to all of AMDs technologies would be, mind you this criticism corrects it self toward the end of the artical.
stance - Monday, March 5, 2007 - link
Remember AMD's old president and CEO Jerry Sanders with commentslike "We will see what we see" and "More bang for your buck" I
cannot wait to see duel socket motherboards with two four core
Barcelona's working their magic. reminds me of Carol shelby
when he brought the Cobra out for road test. exciting is not
the word, jaw droping performance? Don't take Richard's Statements
lightly
lordsnow - Sunday, March 4, 2007 - link
Does anyone have any idea how compatible the "Barcelona" CPU will be with current motherboards? When it comes out, does it need a new n-phase voltage regulator, for example?the reason I'm asking is, I want to upgrade and with the current state of affairs was going to go for a C2D CPU. But with these Barcelona CPU's due out I may stick with AMD - get a AM2 motherboard and cheap AM2 CPU and upgrade to the Barcelona CPU at a later date. But I have to be sure that whatever motherboard I buy now will be 100% Barcelona compatible.
Can anyone inform us about what the situation is in this regard?
coldpower27 - Sunday, March 4, 2007 - link
Barcelona being the server variant will be compatible with the Socket F infrastructure, while Agena will be a Socket AM2+ processor compatible with exisiting Socket AM2 infrastructure.lordsnow - Sunday, March 4, 2007 - link
Any ideas as to what kind of features a user will be missing by dropping a AM2+ "Agena" CPU into a AM2 socket? The enhanced Power Saving features, perhaps?chucky2 - Sunday, March 4, 2007 - link
I asked above and non-AnandTech folks like you and I said it would...but no one from AnandTech themselves jumped right in to give an affirmative.I asked for links from AMD's own website confirming that Agena and Kuma would work in current AM2 motherboards, and no one posted back.
Right now the AM2+ CPU's will work in current AM2 boards rumor is just that, a rumor...when AMD themselves confirm it, or a site such as AnandTech confirms it with AMD and reports on it, then I'll believe it.
Until then, it's <i>probable</i> that AM2+ will work in current AM2 motherboards...if you're willing to take the risk I say go for it, else, wait until we have an official answer one way or the other.
JMHO...
Chuck
Calin - Saturday, March 3, 2007 - link
"Intel regained the undisputed performance crown it hadn't seen ever since the debut of AMD's Athlon 64."Intel in fact lost the "undisputed performance king" title during the early lifetime of the K7 architecture. The Pentium !!! was faster at some tasks and slower at others (games) than the K7. Before that, the Pentium II was better than the K6-2 (the K6-3 had better IPC than Pentium3, but was slower in MHz)
coldpower27 - Sunday, March 4, 2007 - link
Intel had the undisputed performance crown again with the Athlon XP 3200+ vs the Pentium 4 3.0C/3.2C and higher processors.