Barcelona Architecture: AMD on the Counterattack
by Anand Lal Shimpi on March 1, 2007 12:05 AM EST- Posted in
- CPUs
Core Tune-up
While the most significant sounding improvements were rolled into the SSE128 changes in Barcelona, they are merely the tip of the iceberg. The laundry list of improvements to Barcelona starts with the branch predictor.
In general, the accuracy of a CPU's branch predictor determines how wide and how deep of a design you can make. The average number of instructions before the predictor mispredicts governs how many instructions you can have in flight, which in turn controls how many execution units you can realistically keep fed on a regular basis. The K8's branch predictor was quite good and very well optimized for its architecture, but there were some advancements Intel introduced in the Pentium M and Pentium 4 that AMD could stand to benefit from.
Barcelona adds a 512-entry indirect predictor which, believe it or not, predicts indirect branches. An indirect branch is one where the target of the branch is a location pointed to by an address in memory, in other words, a branch with multiple targets. Instead of branching directly to a label indicated by the branch instruction, an indirect branch sends the CPU to a memory location that contains the location of the instruction that it should branch to.
Intel added an indirect predictor to its Pentium M processor based on the idea that the more you could limit the number of mispredicted branches, the more efficient your processor could be (thus lowering power consumption). The indirect predictor also made its way into Prescott in order to help minimize the performance deficit incurred by further pipelining the NetBurst architecture.
In Prescott, the simple addition of an indirect predictor resulted in over a 12% reduction in mispredicted branches in SPEC CPU2000. While details of how AMD and Intel differ in their predictor algorithms aren't public, we can expect similarly large improvements in areas where indirect branches are common. In the 253.perlbmk test of SPEC CPU2000 the reduction in mispredicted branches with Prescott was significant, reaching almost 55%. With Barcelona, fewer mispredicted branches means higher overall IPC and greater efficiency both from a power and performance standpoint. AMD doesn't have the incredibly deep pipeline to worry about that Intel did with Prescott, but the efficiency improvements should be significant.
The inclusion of an indirect predictor wasn't the only crystal ball improvement in Barcelona; the size of the return stack in the new core is double what it was in K8. In very deep call chains, for example code that calls many subroutines (e.g. recursive functions), the CPU will eventually run out of room to keep track of where it has been. Once it starts losing track of return addresses, it loses the ability to predict branches involved with those addresses. Barcelona helps alleviate the problem by doubling the size of the return stack. These sorts of improvements are generally implemented by profiling the behavior of software commonly used on a manufacturer's CPU, so we asked AMD what software or scenario drove this improvement of Barcelona. AMD wouldn't give us a concrete example of a situation other than to say that the return stack size improvements were made at the request of a "large software vendor".
The final improvement to the K8's branch prediction came through the usual channels - Barcelona now tracks more branches than its predecessor. There's no mystic science to branch prediction; a processor simply looks at branches it has taken and bases its predictions on historical data. The more historical data that is present, the more accurate a branch predictor becomes. When the K8 was designed it was built on a 130nm manufacturing process; with the first incarnation of Barcelona set to debut at 65nm AMD definitely has the die space to track more branch history data.
While the most significant sounding improvements were rolled into the SSE128 changes in Barcelona, they are merely the tip of the iceberg. The laundry list of improvements to Barcelona starts with the branch predictor.
In general, the accuracy of a CPU's branch predictor determines how wide and how deep of a design you can make. The average number of instructions before the predictor mispredicts governs how many instructions you can have in flight, which in turn controls how many execution units you can realistically keep fed on a regular basis. The K8's branch predictor was quite good and very well optimized for its architecture, but there were some advancements Intel introduced in the Pentium M and Pentium 4 that AMD could stand to benefit from.
Barcelona adds a 512-entry indirect predictor which, believe it or not, predicts indirect branches. An indirect branch is one where the target of the branch is a location pointed to by an address in memory, in other words, a branch with multiple targets. Instead of branching directly to a label indicated by the branch instruction, an indirect branch sends the CPU to a memory location that contains the location of the instruction that it should branch to.
Intel added an indirect predictor to its Pentium M processor based on the idea that the more you could limit the number of mispredicted branches, the more efficient your processor could be (thus lowering power consumption). The indirect predictor also made its way into Prescott in order to help minimize the performance deficit incurred by further pipelining the NetBurst architecture.
In Prescott, the simple addition of an indirect predictor resulted in over a 12% reduction in mispredicted branches in SPEC CPU2000. While details of how AMD and Intel differ in their predictor algorithms aren't public, we can expect similarly large improvements in areas where indirect branches are common. In the 253.perlbmk test of SPEC CPU2000 the reduction in mispredicted branches with Prescott was significant, reaching almost 55%. With Barcelona, fewer mispredicted branches means higher overall IPC and greater efficiency both from a power and performance standpoint. AMD doesn't have the incredibly deep pipeline to worry about that Intel did with Prescott, but the efficiency improvements should be significant.
The inclusion of an indirect predictor wasn't the only crystal ball improvement in Barcelona; the size of the return stack in the new core is double what it was in K8. In very deep call chains, for example code that calls many subroutines (e.g. recursive functions), the CPU will eventually run out of room to keep track of where it has been. Once it starts losing track of return addresses, it loses the ability to predict branches involved with those addresses. Barcelona helps alleviate the problem by doubling the size of the return stack. These sorts of improvements are generally implemented by profiling the behavior of software commonly used on a manufacturer's CPU, so we asked AMD what software or scenario drove this improvement of Barcelona. AMD wouldn't give us a concrete example of a situation other than to say that the return stack size improvements were made at the request of a "large software vendor".
The final improvement to the K8's branch prediction came through the usual channels - Barcelona now tracks more branches than its predecessor. There's no mystic science to branch prediction; a processor simply looks at branches it has taken and bases its predictions on historical data. The more historical data that is present, the more accurate a branch predictor becomes. When the K8 was designed it was built on a 130nm manufacturing process; with the first incarnation of Barcelona set to debut at 65nm AMD definitely has the die space to track more branch history data.
83 Comments
View All Comments
R3MF - Thursday, March 1, 2007 - link
thanks.a 2.4GHz Agena on an AM2+ mATX motherboard, sat in a tiny SUGO 03 case sounds like a very tempting proposition later on this year.
Macuser89 - Thursday, March 1, 2007 - link
Is it just me or is this article saying that AMD is copying a lot of intel's advancements. Great in depth article AT.Le Québécois - Thursday, March 1, 2007 - link
I may be wrong but I think that new CPU or GPU technologies are planned years ahead so for me it look more like they came down to the "same" conclusion on how to improve their CPU. Only Intel did it 1 year before AMD.JarredWalton - Thursday, March 1, 2007 - link
There are fundamentally only so many ways to improve processor performance, and Intel used most of them with Core 2. That AMD is using similar patterns (more buffers, better branch prediction, wider execution, etc.) isn't at all surprising. Just because the same basic principles are used, however, doesn't mean that at the transistor level there aren't significant differences and challenges to overcome.archcommus - Thursday, March 1, 2007 - link
Another great article that displays all the reasons why I read AT - lengthy, technical reviews written by educated authors that are interesting to read and to top it off, with no typing errors! I'm sure you guys use voice software to write these mammoths.I was waiting for details on Barcelona for so long and this is finally it. I have no doubt that AMD will be up to par with Intel again, but the question is, will this significantly SURPASS Core 2 offerings at the time? I hope so but it's not a definite thing yet.
The best thing is, I'm a ways into my computer engineering degree now so I can actually understand a lot of these very techincal articles!
Le Québécois - Thursday, March 1, 2007 - link
You said:But isn't it the same thing?
I mean mid-2007 is the 1st of july and Q3 also begins with july. Could you be more specific? Maybe the month we can expect them?
JarredWalton - Thursday, March 1, 2007 - link
Q3 means anywhere between July and late September, while mid-2007 means June or July time frame. As the official launch date approaches, we'll refine things where possible.Le Québécois - Thursday, March 1, 2007 - link
Thank you for your quick reply, as usual.mjrpes3 - Thursday, March 1, 2007 - link
Any word on when the desktop variant of Barcelona (Agena) will find its way into consumer's hands?puffpio - Thursday, March 1, 2007 - link
When you refer to DDR3 you call it DDDR3unless...there is a DDDR3 I don't know about?