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.
Facebook
Twitter
RSS
83 Comments
View All Comments
BitByBit - Tuesday, March 6, 2007 - link
One apparently overlooked detail of Barcelona's architecture is its instruction fetch ability: Barcelona is able to send 32 bytes (128 bits) to its decoders per cycle, where Core can send only 16 bytes to be decoded, increasing the likelihood of 'split fetch' cases in the latter. This means that, even if Core does have more raw FP power in terms of its execution units, Barcelona can expect greater utilisation of its FPUs/SSE, and the impact of this will be even more pronounced when running 64 bit code, due to the increased size of 64 bit instruction blocks. If Barcelona does, as expected, outperform Core in IPC in 32 bit mode, the performance gap may well increase in 64 bit mode.JarredWalton - Thursday, March 1, 2007 - link
Did you miss page 3? The SSE128 stuff largely deals with FP and cache improvements. Standard FP is still used, but most programs are optimizing for SSE2/3 as that can run circles around x87 FP performance.Spoelie - Thursday, March 1, 2007 - link
Is there no information on the bandwidth between the new caches? Or are they left the same? I'm only asking because last I read, Intel had a huge advantage in that department, with double or so the bandwidth between the caches. Isn't that important in FP-code, especially if you have to feed 4 cores (so the bw at the level 3 cache..)JarredWalton - Thursday, March 1, 2007 - link
Page 3: the cache bandwidth as I understand it should be doubled (128-bit vs. 64-bit), and several other areas have wider data paths as well. I think Intel has a 256-bit cache bus, so they still have more cache bandwidth, but as a whole it's difficult to say which will end up faster right now. The integrated memory controller has a lot of influence on a lot of areas, after all.Spoelie - Thursday, March 1, 2007 - link
K7 to K8 transition did the doubling of the 64bit interface to the 128bit one.. Core indeed has a 256bit interface (as far as I remember, even the P3 had a 256bit interface to L2). So according to page 3 the interface would be doubled again this time around?I'm only asking because I remember this quote from Johan De Gelas' article a while back.
"The Core architecture's L1 cache delivers about twice as much bandwidth (Measured by ScienceMark), while it's L2-cache is about 2.5 times faster than the Athlon 64/Opteron one."
And that must have *some* impact on performance. I think the bandwidth of the L3 cache will also be key, but haven't seen any official information about it.
BitByBit - Friday, March 2, 2007 - link
K8 had a 64-bit read and a 64-bit write path to its L2 cache, giving a total of 128 bits. Barcelona has a 128-bit read and 128-bit write path to its L2, giving a total of 256 bits - the same as Core.One thing that surprised me on the subject of cache was the associativity of the L1, which I had expected to see increased to 4-way. This would have allowed AMD to extend its lead in L1 hitrate and regain the ground lost in this area since the introduction of Core. Maybe we'll see an improvement to L1 associativity in future iterations of Barcelona.
haplo602 - Thursday, March 1, 2007 - link
Great article, was a very interesting read.Looks like I'll invest in an upgrade sometime beginning of 2008 when these new CPUs make their 2nd revision :-)
Gigahertz19 - Thursday, March 1, 2007 - link
Argh this article is such a cock tease. I read most of it but now I want some prelim benchies or some kind of numbers. Guess we'll have to wait till Mid-2007?I can't stand the anticipation, my girlfriend pulls this same shit every now and then, she'll get me going then quit and laugh....I always tell her I'll pull the same thing on her and see how she likes it but I can never gather up enough will power :)
MrJim - Thursday, March 1, 2007 - link
Hello Anand, great article as always. I suppose your much at home nowadays building your house etc. But when are we going to read more of your blogs or the relaunch of anandtech? I think the plan was to have many of the staff to have their own blogs?Hope you will write more often in the future!
slashbinslashbash - Thursday, March 1, 2007 - link
I agree, I would like to see more Anand blog entries. The blog currently doesn't seem to be working -- I can't pull up any of the older entries. I would like to go back and read through some of the old Macdates.