Sideband Stack Optimizer

Intel's very first Pentium M introduced a feature Intel called its dedicated stack manager. As its name implies, the dedicated stack manager was used to handle all x86 stack operations (i.e. push, pop, call, return). The purpose of the stack manager was to keep those stack operations, which are frequently used with function calls in code, separate from the rest of the x86 instruction stream sent to the CPU. The dedicated stack manager would handle decode and "execution" of these operations so that they wouldn't clog up the processor's decoders and execution units later in the pipeline. Intel essentially "widened" the core by offloading some operations to separate hardware.

With Barcelona, AMD is introducing a similar technology it is calling a Sideband Stack Optimizer. Stack instructions no longer go through the 3-way decoder and stack operations no longer go through the integer execution units, effectively widening Barcelona at minimal cost. The Sideband Stack Optimizer, like Intel's dedicated stack manager, features its own adder that handles all stack operations. It's a small tweak that can help overall performance, and it's simply one that made sense for AMD to implement.

Faster Loads

When looking at the performance of the Athlon 64 and Intel's Core 2 processors, it's easy to understand why Intel has a strong performance advantage in applications that make heavy use of SSE. But what about applications like gaming and business apps that should greatly benefit from AMD's on-die memory controller? Is the Core 2's larger L2 cache and aggressive prefetchers all that it needs to overcome AMD's on-die memory controller?

One major aspect of Intel's Core micro-architecture advantage is its ability to allow load instructions to bypass previous load and store instructions. On average, about 1/3 of all instructions in a program end up being loads, thus if you can improve load performance you can generally impact overall application performance pretty significantly. With Intel's Core micro-architecture, it's possible for loads to be re-ordered to ensure that instructions dependent on those loads get the data they need without waiting for costly memory accesses.

Core also allowed for loads to be moved ahead of stores, which was previously not allowed due to the possibility that an earlier store could invalidate the data that was just loaded. Intel figured that the possibility of a store writing over a load ends up being very small, on the order of 1 - 2%, therefore with a reasonably accurate predictor you could correctly guess when re-ordering a load ahead of a store was possible. Intel's Core 2 based processors feature prediction logic to guess whether a store and a load share the same memory address; if the predictor determines that they won't, then it allows the load to be re-ordered ahead of the store. In the small chance that the predictor is incorrect however, the load has to be redone at the cost of a pipeline flush (similar to what happens if the processor mispredicts a branch).

AMD's K8 architecture had no equivalent scheme for allowing the out of order execution of loads ahead of other loads and stores, so even without an on-die memory controller Intel was able to execute some memory operations faster than AMD. Barcelona fixes this problem through an almost identical scheme to what Intel implemented in its Core 2 processors.

Barcelona can now re-order loads ahead of other loads, just like Core 2 can. It can also execute loads ahead of other stores, assuming that the processor knows that the two don't share the same memory address. While Intel uses a predictor to determine whether or not the store aliases with the load, AMD takes a more conservative approach. Barcelona waits until the store address is calculated before determining whether or not the load can be processed ahead of it. By doing it this way, Barcelona is never wrong and there's no chance of a mispredict penalty. AMD's designers looked at using a predictor like Intel did but found that it offered no performance improvement on its architecture. AMD can generate up to three store addresses per clock as it has three AGUs (Address Generation Units) compared to Intel's one for stores, so it would make sense that AMD has a bit more execution power to calculate a store address before moving a load ahead of it.

The out of order load execution improvements to Barcelona should prove to be even more effective than they were in Core 2 given that AMD previously couldn't do any reordering of loads before the Int/FP schedulers whereas Core Duo could do a limited amount of re-ordering.

Core Tune-up Even More Tweaks
POST A COMMENT

83 Comments

View All Comments

  • BitByBit - Tuesday, March 06, 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. Reply
  • JarredWalton - Thursday, March 01, 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. Reply
  • Spoelie - Thursday, March 01, 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..) Reply
  • JarredWalton - Thursday, March 01, 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. Reply
  • Spoelie - Thursday, March 01, 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.
    Reply
  • BitByBit - Friday, March 02, 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.
    Reply
  • haplo602 - Thursday, March 01, 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 :-)
    Reply
  • Gigahertz19 - Thursday, March 01, 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 :)
    Reply
  • MrJim - Thursday, March 01, 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!
    Reply
  • slashbinslashbash - Thursday, March 01, 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. Reply

Log in

Don't have an account? Sign up now