The Pursuit of Clock Speed

Thus far I have pointed out that a number of resources in Bulldozer have gone down in number compared to their abundance in AMD's Phenom II architecture. Many of these tradeoffs were made in order to keep die size in check while adding new features (e.g. wider front end, larger queues/data structures, new instruction support). Everywhere from the Bulldozer front-end through the execution clusters, AMD's opportunity to increase performance depends on both efficiency and clock speed. Bulldozer has to make better use of its resources than Phenom II as well as run at higher frequencies to outperform its predecessor. As a result, a major target for Bulldozer was to be able to scale to higher clock speeds.

AMD's architects called this pursuit a low gate count per pipeline stage design. By reducing the number of gates per pipeline stage, you reduce the time spent in each stage and can increase the overall frequency of the processor. If this sounds familiar, it's because Intel used similar logic in the creation of the Pentium 4.

Where Bulldozer is different is AMD insists the design didn't aggressively pursue frequency like the P4, but rather aggressively pursued gate count reduction per stage. According to AMD, the former results in power problems while the latter is more manageable.

AMD's target for Bulldozer was a 30% higher frequency than the previous generation architecture. Unfortunately that's a fairly vague statement and I couldn't get AMD to commit to anything more pronounced, but if we look at the top-end Phenom II X6 at 3.3GHz a 30% increase in frequency would put Bulldozer at 4.3GHz.

Unfortunately 4.3GHz isn't what the top-end AMD FX CPU ships at. The best we'll get at launch is 3.6GHz, a meager 9% increase over the outgoing architecture. Turbo Core does get AMD close to those initial frequency targets, however the turbo frequencies are only typically seen for very short periods of time.

As you may remember from the Pentium 4 days, a significantly deeper pipeline can bring with it significant penalties. We have two prior examples of architectures that increased pipeline length over their predecessors: Willamette and Prescott.

Willamette doubled the pipeline length of the P6 and it was due to make up for it by the corresponding increase in clock frequency. If you do less per clock cycle, you need to throw more clock cycles at the problem to have a neutral impact on performance. Although Willamette ran at higher clock speeds than the outgoing P6 architecture, the increase in frequency was gated by process technology. It wasn't until Northwood arrived that Intel could hit the clock speeds required to truly put distance between its newest and older architectures.

Prescott lengthened the pipeline once more, this time quite significantly. Much to our surprise however, thanks to a lot of clever work on the architecture side Intel was able to keep average instructions executed per clock constant while increasing the length of the pipe. This enabled Prescott to hit higher frequencies and deliver more performance at the same time, without starting at an inherent disadvantage. Where Prescott did fall short however was in the power consumption department. Running at extremely high frequencies required very high voltages and as a result, power consumption skyrocketed.

AMD's goal with Bulldozer was to have IPC remain constant compared to its predecessor, while increasing frequency, similar to Prescott. If IPC can remain constant, any frequency increases will translate into performance advantages. AMD attempted to do this through a wider front end, larger data structures within the chip and a wider execution path through each core. In many senses it succeeded, however single threaded performance still took a hit compared to Phenom II:


Cinebench 11.5 - Single Threaded

At the same clock speed, Phenom II is almost 7% faster per core than Bulldozer according to our Cinebench results. This takes into account all of the aforementioned IPC improvements. Despite AMD's efforts, IPC went down.

A slight reduction in IPC however is easily made up for by an increase in operating frequency. Unfortunately, it doesn't appear that AMD was able to hit the clock targets it needed for Bulldozer this time around.

We've recently reported on Global Foundries' issues with 32nm yields. I can't help but wonder if the same type of issues that are impacting Llano today are also holding Bulldozer back.

The Architecture Power Management and Real Turbo Core
Comments Locked


View All Comments

  • nofumble62 - Thursday, October 13, 2011 - link

    Crappy building block will mean crappy building.
  • richaron - Friday, October 14, 2011 - link

    At first I was pissed off by being strung along for this pile of tripe. After sleeping on it, I am not completely giving up on this SERVER CHIP:
    1) FX is a performance moniker, scratch stupid amount of cache & crank clock
    2) I'm sure these numbties can get single thread up to thuban levels
    3) Patch windows scheduler ffs
    Fix those (relatively simple) things & it will kick ass. But it means most enthusiasts wont be spending money on AMD for a while yet.
  • 7Enigma - Friday, October 14, 2011 - link

    Biggest problem for a server chip is the load power levels. It just doesn't compete on that benchmark and one in which is VERY important for a server environment from a cost/heat standpoint.

    Let's hope that's just a crappy leaky chip due to manufacturing but it's to early to tell.
  • richaron - Friday, October 14, 2011 - link

    I've worked in a 'server environment'. of course power consumption is an issue. at the lower clock speeds & considering multithread performance, this is already a good/great contender. virtual servers & scientific computing this is already a winnar.
    with a few (hardware & software) tweaks it could be a GREAT pc chip in the long term.
  • ryansh - Friday, October 14, 2011 - link

    Anyone have a BETA copy of WIN8 to see if BD's performance increases like AMD says it will.
  • silverblue - Friday, October 14, 2011 - link

    There's benchmarks here and there but nothing to say it'll improve performance more than 10% across the board. In any case, the competition also benefits from Windows 8, so it's still not a sign of AMD closing any sort of gap in a tangible fashion.
  • Pipperox - Friday, October 14, 2011 - link

    But Bulldozer is different.
    Windows 7 scheduler does not have a clue about its "modules" and "cores".
    So for example it may find it perfectly legit to schedule 2 FP intensive threads to the same module.
    Instead this will result in reduced performance on Bulldozer.
    Also one may want to schedule two integer threads which share the same memory space to the same module, instead of 2 different modules.
    This way the two threads can share the same L2 cache, instead of having to go to the L3 which would increase latency.

    All of the above does not apply to Thuban; to a lesser degree it applies to Sandy Bridge, but Windows 7 scheduler is already aware of Sandy Bridge's architecture.
  • nirmv - Saturday, October 15, 2011 - link

    Pipperox, It's not different than Intel's Hyper Threading.
  • Pipperox - Sunday, October 16, 2011 - link

    It is, although they're similar concepts.
    Let's make an example: you have 2 integer threads working on the same address space (for example two parallel threads working in the same process).
    All cores are idle.
    What is the best scheduling for a Hyperthreading cpu?
    You schedule each thread to a different core, so that they can enjoy full execution resources.

    What is best on Bulldozer?
    You schedule them to the SAME module.
    This because the execution resources are split in a BD module, so there would be no advantage to schedule the threads to different modules.
    HOWEVER if the 2 threads are on the same module, they can share the L2 cache instead of the L3 cache on BD, so they enjoy lower memory latency and higher bandwidth.

    There are cases where the above is not true, of course.

    But my example shows that optimal scheduling for Hyperthreading can be SUB-optimal on Bulldozer.

    Hence the need for a Bulldozer-aware scheduler in Windows 8.
  • Regs - Friday, October 14, 2011 - link

    AMD needs a 40-50% performance gain and they're not going to see it using windows 8. What AMD needs is...actually I have no clue what the need. I've never been so dumbfounded about a product that makes no sense or has any position in the market.

Log in

Don't have an account? Sign up now