AMD Virtualization Improvements

The performance-related improvement to Barcelona comes in the way of speeding up virtualized address translation. In a virtualized software stack where you have multiple guest OSes running on a hypervisor there's a new form of memory address translation that must be dealt with: guest OS to hypervisor address translation, as each guest OS has its own independent memory management. According to AMD, currently this new layer of address translation is handled in software through a technique called shadow paging. What Barcelona offers is a hardware accelerated alternative to shadow paging, which AMD is calling Nested Paging.

Supposedly up to 75% of the hypervisor's time can be spent dealing with shadow pages, which AMD eliminates by teaching the hardware about both guest and host page tables. The translated addresses are cached in Barcelona's new larger TLBs to further improve performance. AMD indicates that Barcelona's support for Nested Paging requires very little to implement; simply setting a mode bit should suffice, making the change easy for software vendors to implement.

Power Management

The most recent aspect of Barcelona's design that AMD revealed is how it handles power management. Although all four cores still operate on the same power plane (same voltage), Barcelona's Northbridge now runs on a separate power plane. Barcelona's core and Northbridge voltages can vary between 0.8V - 1.4V independently of one another.

In a conventional platform architecture, the Northbridge and the CPU are already on separate power planes given that the Northbridge is external to the CPU. The benefit of this arrangement is that the two chips can power down independently of one another, so when the memory controller has little to do, it can power down until needed. With AMD's K8, this wasn't true as the Northbridge and CPU core(s) were on the same power plane. In Barcelona, they are separated to improve power efficiency.

The individual cores still share the same reference voltage, but each core has its own PLL so that they can run at different clock speeds depending on load. While voltages of all four cores have to be equal, clock speed and thus current draw can be reduced depending on load - which will amount to power savings under normal usage conditions. The implications on the desktop are particularly interesting since it's rare that most desktop workloads will keep all cores pegged at 100% utilization.

Barcelona supports up to 5 independent p-states for each core, varying only in clock speed. The p-states are completely hardware controlled, so you will not need a driver to enable support for the power management features. AMD also increased the amount of clock gating done on Barcelona compared to K8 at both the block level and logic level. AMD wouldn't give us any more detail than this, but given how long it's been since the K8's introduction we'd expect that there's a lot that can be done.

The performance efficiency enhancements to Barcelona, coupled with updated power management, further clock gating and 65nm process allow AMD's first quad core part to operate within the same thermal envelope as current Opterons.

Getting Spendy with Transistors - L3 cache Final Words
Comments Locked

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.

Log in

Don't have an account? Sign up now