What to Expect From AMD at ISSCC 2011

[marten_larsson]

Agreed, it's the best of both worlds when it comes to multithreading and IPC.

If you're a guy who doesn't need more than 4 cores, the cores get the FPU and cache to themselves and thus more single threaded performance.*

If you're a guy who likes threaded applications, you get to leverage the threaded power of the architecture for more threaded performance.

*I'm curious to know if the Bulldozer design tries to prioritize single threaded apps to their own modules, does anyone know if this is the case?

It could be more efficient to use one module if that means it can turbo (higher) instead of two when using a lower amount of threads. At least from a power consumption perspective it could be smarter to use one module instead of two.

2 threads in a module at 90% IPC of seperate modules at 110% speed will be ~100% performance but power consumption should be lower.

[informal]

Good points marten_larsson. There are still a few things we don't know about the design,so I guess we should wait and see how the cores are handling the workloads when workload is less threaded(than the core count).

[rcofell]

Agreed, it's the best of both worlds when it comes to multithreading and IPC.

If you're a guy who doesn't need more than 4 cores, the cores get the FPU and cache to themselves and thus more single threaded performance.*

If you're a guy who likes threaded applications, you get to leverage the threaded power of the architecture for more threaded performance.

*I'm curious to know if the Bulldozer design tries to prioritize single threaded apps to their own modules, does anyone know if this is the case?

I would expect that responsibility ultimately ends up at the OS thread scheduler's mercy (or use of direct thread binding). It should still pose a similar situation as Hyper-Threading/SMT, the scheduler could use whatever logical processors it wants, however it *might* not necessarily know how to optimize for the underlying micro-architectural implications, e.g. the logical to physical mapping and their resource-sharing relation.

The more I hear about Bulldozer, the more I see it as an adaptation of the ideas inherent in the UltraSPARC T2/3 architecture, with AMD mainly emphasizing single-thread latency instead of going all out on throughput

[Manicdan]

It could be more efficient to use one module if that means it can turbo (higher) instead of two when using a lower amount of threads. At least from a power consumption perspective it could be smarter to use one module instead of two.

2 threads in a module at 90% IPC of seperate modules at 110% speed will be ~100% performance but power consumption should be lower.

i think i understand what you mean

example:
4 threads each on their own module might use 70% of the TDP and overclock 10-15%
vs
4 threads on 2 modules which would use about 50% of the TDP and overclock 20-25%, but have 5-10% less IPC due to shared resources.

in the end it might actually break even or be negligible differences for either route, which is kinda good since it means no matter how messed up windows is at deciding threads, BD knows how to overclock for max performance.

[informal]

Manicdan there is also a cooperative prefetch bonus when threads share same L2 cache,which in turn may increase the performance to some degree.But maybe it's already counted in the already mentioned 80% boost when module is fully loaded. The shared frontend will act similarly to intel's SMT in other beneficiary way:it will smooth out inefficient usage by filling unused integer pipelines as quickly as possible ,just as SMT functionality does on one intel Nehalem/SB core.Only in AMD's case we have a whole core to grab the data,not just a vacant port in the execution stack .That's why AMD can see 80% increase from 2 threads and intel sees 20%-25%.

[Aten-Ra]

It appears that it's been pulled.
Found another source:



One extra integer pipeline, then?
Looks like a damn smart and efficient design, tbh, hope it works out well...

If im not mistaken, DENEBs integer Execution unit has 3 integer pipes PLUS 3 Loas/Store (AGUs) pipes when Bulldozer Integer Execution Unit has 2 integer pipes PLUS 2 AGen(Address Generator).

So we have 3 int pipes for DENEB vs 2 int pipes for each BD Integer Execution Unit.

[madcho]

If im not mistaken, DENEBs integer Execution unit has 3 integer pipes PLUS 3 Loas/Store (AGUs) pipes when Bulldozer Integer Execution Unit has 2 integer pipes PLUS 2 AGen(Address Generator).

So we have 3 int pipes for DENEB vs 2 int pipes for each BD Integer Execution Unit.

it's 3 ALU/AGU for K10, they are general pipes. ( the third pipes give 5% more performance said by AMD ).

it's 2 specialised ALU, and 2 specialised AGU. so it's more faster on integer on Bulldozer. And i think this is a more efficient disign about power comsuption.

[andos]

http://www.cebit.de/en/about-the-tra...tarke-leistung

Oh boy!

[zalbard]

http://www.cebit.de/en/about-the-tra...tarke-leistung

Oh boy!

That's early! Epic!

Edit: wait, it's not a release, it's a presentation. Or do I get it wrong?

[Manicdan]

ok lets all hold hands and pray for just one benchmark

[FlawleZ]

http://www.cebit.de/en/about-the-tra...tarke-leistung

Oh boy!

How credible would we consider cebit here?

[zalbard]

How credible would we consider cebit here?

That's an official statement.

[informal]

That's the official Cebit page... Pretty credible if you ask me. But unveiling does not equate launching.

[god_43]

That's the official Cebit page... Pretty credible if you ask me. But unveiling does not equate launching.

if it is 50% then... it has to be BD? perhaps they will name them phenom III?

[Aten-Ra]

it's 3 ALU/AGU for K10, they are general pipes. ( the third pipes give 5% more performance said by AMD ).

it's 2 specialised ALU, and 2 specialised AGU. so it's more faster on integer on Bulldozer. And i think this is a more efficient disign about power comsuption.

Well, first the above slide is a little bit misleading for someone that dont knows the DENEB (Magny Cours) architecture.

Secondly i believe the slide wants to show the difference of the CMP vs Bulldozers Cluster-Based Multithreading design and so the slide is not an accurate representation of Denebs (Magny Cours) Integer/fp Execution Units.

Denebs integer execution unit has 6x pipelines, 3x ALUs (Integer) and 3x AGUs (Load/Store) and the Integer Scheduler can issue 6x MicroOP (uops) to it.

Bulldozer integer execution unit has 4x pipelines, 2x ALUs (Integer) and 2x AGen(Address Generators) Plus a Load/Store unit (40 Load/24 Store) and the Integer Scheduler can issue 4 uops to it.

The DENEB don’t have FP FMACs but 3x Pipelines, FADD, FMUL,FMISC
Bulldozer FP has 4x pipelines, 2x 128-bit FMACs and 2x 128-bit MMX and one FP shared Scheduler that can issue 4x uops to the FP execution unit.

[god_43]

lol isnt the MC pic supposed to be of bobcat?

[Oliverda]

if it is 50% then... it has to be BD? perhaps they will name them phenom III?

No more Phenom, no more Athlon. Probably it will be simply called AMD FX.

[Manicdan]

Denebs integer execution unit has 6x pipelines, 3x ALUs (Integer) and 3x AGUs (Load/Store) and the Integer Scheduler can issue 6x MicroOP (uops) to it.

Bulldozer integer execution unit has 4x pipelines, 2x ALUs (Integer) and 2x AGen(Address Generators) Plus a Load/Store unit (40 Load/24 Store) and the Integer Scheduler can issue 4 uops to it.

i think your mixing up one major thing
deneb has 3x pipelines, but they can do EITHER, NOT BOTH at the same time.

so 2 alu and 1 alg
or 3 alg and 0 alu
but not 3 and 3 at the same time

BD is always going to do 2 alg and 2 alu per core

[genetix]

First of don't like the design nor do I trust the bold assumption/statement made for bulldozer here (perhaps, just have to see myself as currently still consider AMD making same mistake than Intel). Also, I think HT calculation is a bit inaccurate considering ratio is closer to 165% not 118% (and not by being intel fanboy just been testing a lot of their cores), but even this 165% sucks as it's never stable for general application code for real cores. I wonder what would similar application pressure do to AMD bulldozer like server database pressure against high clock would it uberly fail like Intel's HT or still calculate correctly.

What ever happened to 'real cores' only strategy.

[freeloader]

First of don't like the design nor do I trust the bold assumption/statement made for bulldozer here (perhaps, just have to see myself as currently still consider AMD making same mistake than Intel). Also, I think HT calculation is a bit inaccurate considering ratio is closer to 165% not 118% (and not by being intel fanboy just been testing a lot of their cores), but even this 165% sucks as it's never stable for general application code for real cores. I wonder what would similar application pressure do to AMD bulldozer like server database pressure against high clock would it uberly fail like Intel's HT or still calculate correctly.

What ever happened to 'real cores' only strategy.

"Real cores" still exist. Instead of using up die space for real cores, AMD has managed to almost achieve the performance of two real cores by using shared resources. Think about it. You can achieve 85 to 90% performance of two real cores with 1 module but you're reducing logic die space, heat and power consumption. All good IMHO.

[genetix]

"Real cores" still exist. Instead of using up die space for real cores, AMD has managed to almost achieve the performance of two real cores by using shared resources. Think about it. You can achieve 85 to 90% performance of two real cores with 1 module but you're reducing logic die space, heat and power consumption. All good IMHO.

I do understand this. I just prefer solid real cores only no matter would the "virtualized" cores do clean 200% that only means so could the actual module/core. Makes big decesion when we talk about real cores if it comes up to 4 modules or clean 8 core XEON you can be pretty sure it ain't gonna be modules

but that's an bad example I am just saying I dislike the idea how current architectures are build.

[JumpingJack]

Good points marten_larsson. There are still a few things we don't know about the design,so I guess we should wait and see how the cores are handling the workloads when workload is less threaded(than the core count).

Just a reminder -- the CPU does not schedule, the OS does. Questions about how threads are distributed should be investigated at the OS level. I.e. How much has AMD worked with MS to understand the most effective, efficient scheduling?

[informal]

I think JF once said they are collaborating with MS on how BD thread scheduling will be handled per AMD's own suggestions(since they should know best as day designed the thing ).

[JumpingJack]

I think JF once said they are collaborating with MS on how BD thread scheduling will be handled per AMD's own suggestions(since they should know best as day designed the thing ).

Yep. Wouldn't surprise me. Regardless if it is SMT or CMT, there is an asymmetric distribution of resources between two shared vs two physically different cores (or modules to retain the same level of meaning).

Best performance would to distribute over module first then pair up. I am certain this is being comprehended within the OS for BD.

[Aten-Ra]

i think your mixing up one major thing
deneb has 3x pipelines, but they can do EITHER, NOT BOTH at the same time.

so 2 alu and 1 alg
or 3 alg and 0 alu
but not 3 and 3 at the same time

BD is always going to do 2 alg and 2 alu per core

Yes my bad, Deneb has 3 pipes