What to Expect From AMD at ISSCC 2011

[EvilOne]

By not doing his research you mean not copying down what the engineer said correctly? You in denial or something?

Your not related to terrace215 are you ? Ill trust JF-AMD over a news artical which is using the magic 90% number incorrectly.


EDIT
Found the quote i was looking for.

<totally rhetorical question, NOT real numbers>
Which would you rather have:
80% of the performance with 50% of the cost and 50% of the power consumption
100% of the performance with 120% of the cost and 120% of the power consumption
</end rhetorical question>

People keep seeing that 80% number and thinking that it is a compromise. What they don't understand is that by sharing components we are able to add more cores in the same die space and same power budget.

It is by no means 80% of today's performance.

[informal]

By not doing his research you mean not copying down what the engineer said correctly? You in denial or something?

How about we just wait a bit and read the articles from other sources?
We have all heard the 90% claim which came from 80% performance improvement a module sees when fully loaded(as opposed to 90-100% that 10h dual core sees). My guess is that the reporter just didn't understand what's being said in the presentation. AMD's goal was clearly to milk almost perfect scaling from a fused compute unit having shared resources between two functional and independent cores.They seem to achieve this goal by claiming an average speed-up of 80%(or 1.8x) which equates to 0.9x or 90% per core,when fully loaded module is observed. Nothing to do with direct "K10.5" IPC comparison or whatever previous core AMD developed. Just the scaling of cores inside compute unit(module) and relatively small die investment for the claimed 1.8x throughput scaling.

[Oliverda]

Still no any news about last day's presentation?

This eetimes article is just a rewrite of the informations from the event's program.

[FlanK3r]

hm, maybe they thought if X2=100% in multithreading, then 1 modul=90% in multithreading? Some as % efectivity comparsion to K10.5?

[Sn0wm@n]

Still no any news about last day's presentation?

This eetimes article is just a rewrite of the informations from the event's program.

ding ding ding!!! we have a winner

[mAJORD]

"issue up to four instructions per cycle. The unit helps the core meet its target of delivering 90 percent of performance of past AMD cores"


Hangon.. 4 issue front end helps achieve 90% of the performance of a 3 issue front end?

..EEtimes article has issues.

as said, 90% the performance of an equivilent dual core, was AMD's statement. Which says nothing about end performance (it could be rubbish, good, or somewhere inbetween)

[FlanK3r]

JF, help us

[PatRaceTin]

I expect high overclock

[FlanK3r]

yes, but I thought, per clock will be Zambezi about 20-25% better than K10.5. And dont expect clock higher than 3.5 GHz on start at stock....

[Sn0wm@n]

JF-AMD wont help us before launch day or until the nda's are off at least ...

but then again guys we have at best 3 months before the product hits the shelf ... so it aint that bad of a wait anymore

[Game_boy]

JF-AMD wont help us before launch day or until the nda's are off at least ...

I think JF can help us, by confirming that IPC increases (as he's said before). Because that 90% reads like a decrease.

[cesariuth]

Some new info from ISSCC???

[AKM]

With 90% performance compared to the old core it better damn turbo like crazy, but will that be enough to compete with say an i5-2400 in software that can't make use of it's eight cores?

[Musho]

It isn't performing 90% of current AMD cores, because JF-AMD already said bulldozer would have higher IPC. What they mean (as I understand it), is that when a module is fully loaded, the individual cores in that module are performing at 90% of their maximum performance when only one of the cores in that module would be loaded. The reason why performance per core goes down to 90% when the module is fully loaded, is because both cores in the same module share some of the resources. In my opinion, the performance hit for sharing resources is _really_ small.

[JkS]

I don't know if the reporter got something wrong but I remember hearing the 90% performance of todays cores with low power in the past meaning the Bobcat core.

It sounds like a mixup.

Anyone who still goes on about it, do you really think AMD would release a highly awaited top end processor that is a downgrade in performance? camon, really?

[AKM]

Anyone who still goes on about it, do you really think AMD would release a highly awaited top end processor that is a downgrade in performance? camon, really?

Well it wouldn't really be a downgrade since BD will clock higher and have an aggressive turbo mode.

[JF-AMD]

OK, daddy is going to do some math, everyone follow along please.

First: There is only ONE performance number that has been legally cleared, 16-core Interlagos will give 50% more throughput than 12-core Opteron 6100. This is a statement about throughput and about server workloads only. You CANNOT make any client performance assumptions about that statement.

Now, let's get started.

First, everything that I am about to say below is about THROUGHPUT and throughput is different than speed. If you do not understand that, then please stop reading here.

Second, ALL comparisons are against the same cores, these are not comparison different generations nor are they comparisons against different architectures.

Assume that a processor core has 100% throughput.

Adding a second core to an architecture is typically going to give ~95% greater throughput. There is obviously some overhead because the threads will stall, the threads will wait for each other and the threads may share data. So, two completely independent cores would equal 195% (100% for the first core, 95% for the second core.)


Looking at SPEC int and SPEC FP, Hyperthreading gives you 14% greater throughput for integer and 22% greater throughput for FP. Let's just average the two together.

One core is 100%. Two cores are 118%. Everyone following so far? We have 195% for 2 threads on 2 cores and we have 118% for 2 threads on 1 core.

Now, one bulldozer core is 100%. Running 2 threads on 2 seperate modules would lead to ~195%, it's consistent with running on two independent cores.

Running 2 threads on the same module is ~180%.

You can see why the strategy is more appealing than HT when it comes to threaded workloads. And, yes, the world is becoming more threaded.

Now, where does the 90% come from? What is 180% /2? 90%.

People have argued that there is a 10% overhead for sharing because you are not getting 200%. But, as we saw before, 2 cores actually only equals 195%, so the net per core if you divide the workload is actually 97.5%, so it is roughly a 7-8% delta from just having cores.

Now, before anyone starts complaining about this overhead and saying that AMD is compromising single thread performance (because the fanboys will), keep in mind that a processor with HT equals ~118% for 2 threads, so per thread that equals 59%, so there is a ~36% hit for HT. This is specifically why I think that people need to stay away from talking about it. If you want to pick on AMD for the 7-8%, you have to acknowledge the ~36% hit from HT. But ultimately that is not how people jusdge these things. Having 5 people in a car consumes more gas than driving alone, but nobody talks about the increase in gas consumption because it is so much less than 5 individual cars driving to the same place.

So, now you know the approximate metrics about how the numbers work out. But what does that mean to a processor? Well, let's do some rough math to show where the architecture shines.

An Orochi die has 8 cores. Let's say, for sake of argument, that if we blew up the design and said not modules, only independent cores, we'd end up with about 6 cores.

Now let's compare the two with the assumption that all of the cores are independent on one and in modules on the other. For sake of argument we will assume that all cores scale identically and that all modules scale identically. The fact that incremental cores scale to something less than 100% is already comprehended in the 180% number, so don't fixate on that. In reality the 3rd core would not be at 95% but we are holding that constant for example.

Mythical 6-core bulldozer:
100% + 95% + 95% + 95% + 95% + 95% = 575%

Orochi die with 4 modules:
180% + 180% + 180% + 180% = 720%

What if we had just done a 4 core and added HT (keeping in the same die space):
100% + 95% +95% +95% + 18% + 18% + 18% + 18% = 457%

What about a 6 core with HT (has to assume more die space):
100% + 95% +95% +95% +95% +95% + 18% + 18% + 18% + 18% + 18% + 18% = 683%

(Spoiler alert - this is a comparison using the same cores, do NOT start saying that there is a 25% performance gain over a 6-core Thuban, which I am sure someone is already starting to type.)

The reality is that by making the architecture modular and by sharing some resources you are able to squeeze more throughput out of the design than if you tried to use independent cores or tried to use HT. In the last example I did not take into consideration that the HT circuitry would have delivered an extra 5% circuitry overhead....

Every design has some degree of tradeoff involved, there is no free lunch. The goal behind BD was to increase core count and get more throughput. Because cores scale better than HT, it's the most predictable way to get there.

When you do the math on die space vs. throughput, you find that adding more cores is the best way to get to higher throughput. Taking a small hit on overall performance but having the extra space for additional cores is a much better tradeoff in my mind.

Nothing I have provided above would allow anyone to make a performance estimate of BD vs. either our current architecture or our compeition, so, everyone please use this as a learning experience and do not try to make a performance estimate, OK?

[generics_user]

I don't know if the reporter got something wrong but I remember hearing the 90% performance of todays cores with low power in the past meaning the Bobcat core.

It sounds like a mixup.

Anyone who still goes on about it, do you really think AMD would release a highly awaited top end processor that is a downgrade in performance? camon, really?

QFT

bobcat is 90% of todays cores clock/clock

why should a more than 2 times wider core (one modules is more than 4 4times wider than a bobcat core) with a significantly more advanced memory subsystem perform the same as bobcat????

this 90% performance of K10 number is complete nonsense and eetimes failed big time with their article

[Sn0wm@n]

I think JF can help us, by confirming that IPC increases (as he's said before). Because that 90% reads like a decrease.

it allready has been posted on this very own thread and in other threads... thanks for making it your very first post in this forum tho

With 90% performance compared to the old core it better damn turbo like crazy, but will that be enough to compete with say an i5-2400 in software that can't make use of it's eight cores?

again ... it has been said multiple times by JF-AMD who was autorised and cleared by amd's legal team to say to us that bulldozer will have an ipc increase ... where do you think that informal's funny quote came from???


the same thread that jf-amd confirmed the icp increase .... so can we please stop saying this nonsense about a decrease in performance ....

[freeloader]

it allready has been posted on this very own thread and in other threads... thanks for making it your very first post in this forum tho








again ... it has been said multiple times by JF-AMD who was autorised and cleared by amd's legal team to say to us that bulldozer will have an ipc increase ... where do you think that informal's funny quote came from???


the same thread that jf-amd confirmed the icp increase .... so can we please stop saying this nonsense about a decrease in performance ....

Until I see numbers, I'll assume the worse and say it's a 50% decrease. Thats why all of AMD's management is leaving because they know a disaster is looming. I'm being totally sarcastic of course, but you can see what effect the secrecy is having on the general public. Most people I speak to think AMD's next chip is going to be a turd.

[Sn0wm@n]

Until I see numbers, I'll assume the worse and say it's a 50% decrease. Thats why all of AMD's management is leaving because they know a disaster is looming. I'm being totally sarcastic of course, but you can see what effect the secrecy is having on the general public. Most people I speak to think AMD's next chip is going to be a turd.

cant blame amd for being secretive about a 10 year long project can we???

[informal]

Thanks JF-AMD for additional clarifications!

More info at official BD blog:

http://blogs.amd.com/work/2011/02/21...ign-solutions/

This paper also details design of the Bulldozer Floating Point Unit (FPU) shown in Figure 2. High performance computing relies heavily on vector (packed integer) and floating point operations, both handled in the FPU. Bulldozer was designed to execute these operations at higher performance and using less power than the current generation of microprocessors. Key to Bulldozer’s performance and power improvements are FPU changes, including completely redesigned arithmetic units and control structures. This paper covers logic and circuit design goals and tradeoffs for the FP scheduler, datapaths, and register files. As previously described at HotChips 2010, the Bulldozer FPU supports new instructions including SSSE3, SSE4.1, SSE4.2, AVX, AES, and advanced Multiply-Add/Accumulate operations. Fitting these features into the available silicon area, power, and frequency required significant circuit innovations, including pipeline restructuring and a completely new floorplan.

Changes to the Integer Execution Unit will be described in another ISSCC paper (Session 4.6) titled “40-entry Unified, Out-of-Order Scheduler and Integer Execution Unit for the AMD Bulldozer x86-64 Core” (http://isscc.org/program/index.html). “Bulldozer’s” integer data and processor control sequencing are handled in the Integer Execution Unit (EX). This unit consists of a 1-cycle out-of-order instruction scheduler, four integer pipelines, and a Level1 Data Cache. The design also includes significant circuit and floorplan changes to improve frequency (speed) while reducing per core power rating over previous designs. Handling up to four 64-bit instructions per thread, the EX unit improves instruction scheduling and execution while significantly improving frequency and power over previous designs. The ISSCC paper will describe the logic and circuit design of the EX instruction scheduler and datapaths. It will also detail how Bulldozer’s high frequency is achieved using robust, reliable circuit designs.

http://blogs.amd.com/work/2011/02/21...hats-in-a-box/

So what’s inside those boxes? I’ll give some insight here, but today at ISSCC I’ll present Paper 4.6, “40-Entry unified Out-of-Order Scheduler and Integer Execution Unit for the AMD Bulldozer x86-64 Core,” to discuss the physical design of the scheduler and execution unit for AMD’s two-core Bulldozer module. Even though the module allows AMD to build a chip with many cores on a single die, single-threaded integer performance cannot be compromised. The out-of-order scheduler must efficiently pick up to four ready instructions for execution and wake up dependent instructions so that they may be picked in the next cycle. The execution units must compute results in a single cycle and forward them to dependent operations in the following cycle. All of this is required so that the module gives high architectural performance, measured in the number of instructions completed per cycle (IPC).

[eXceeded]

OK, daddy is going to do some math, everyone follow along please.

First: There is only ONE performance number that has been legally cleared, 16-core Interlagos will give 50% more throughput than 12-core Opteron 6100. This is a statement about throughput and about server workloads only. You CANNOT make any client performance assumptions about that statement.

Now, let's get started.

First, everything that I am about to say below is about THROUGHPUT and throughput is different than speed. If you do not understand that, then please stop reading here.

Second, ALL comparisons are against the same cores, these are not comparison different generations nor are they comparisons against different architectures.

Assume that a processor core has 100% throughput.

Adding a second core to an architecture is typically going to give ~95% greater throughput. There is obviously some overhead because the threads will stall, the threads will wait for each other and the threads may share data. So, two completely independent cores would equal 195% (100% for the first core, 95% for the second core.)


Looking at SPEC int and SPEC FP, Hyperthreading gives you 14% greater throughput for integer and 22% greater throughput for FP. Let's just average the two together.

One core is 100%. Two cores are 118%. Everyone following so far? We have 195% for 2 threads on 2 cores and we have 118% for 2 threads on 1 core.

Now, one bulldozer core is 100%. Running 2 threads on 2 seperate modules would lead to ~195%, it's consistent with running on two independent cores.

Running 2 threads on the same module is ~180%.

You can see why the strategy is more appealing than HT when it comes to threaded workloads. And, yes, the world is becoming more threaded.

Now, where does the 90% come from? What is 180% /2? 90%.

People have argued that there is a 10% overhead for sharing because you are not getting 200%. But, as we saw before, 2 cores actually only equals 195%, so the net per core if you divide the workload is actually 97.5%, so it is roughly a 7-8% delta from just having cores.

Now, before anyone starts complaining about this overhead and saying that AMD is compromising single thread performance (because the fanboys will), keep in mind that a processor with HT equals ~118% for 2 threads, so per thread that equals 59%, so there is a ~36% hit for HT. This is specifically why I think that people need to stay away from talking about it. If you want to pick on AMD for the 7-8%, you have to acknowledge the ~36% hit from HT. But ultimately that is not how people jusdge these things. Having 5 people in a car consumes more gas than driving alone, but nobody talks about the increase in gas consumption because it is so much less than 5 individual cars driving to the same place.

So, now you know the approximate metrics about how the numbers work out. But what does that mean to a processor? Well, let's do some rough math to show where the architecture shines.

An Orochi die has 8 cores. Let's say, for sake of argument, that if we blew up the design and said not modules, only independent cores, we'd end up with about 6 cores.

Now let's compare the two with the assumption that all of the cores are independent on one and in modules on the other. For sake of argument we will assume that all cores scale identically and that all modules scale identically. The fact that incremental cores scale to something less than 100% is already comprehended in the 180% number, so don't fixate on that. In reality the 3rd core would not be at 95% but we are holding that constant for example.

Mythical 6-core bulldozer:
100% + 95% + 95% + 95% + 95% + 95% = 575%

Orochi die with 4 modules:
180% + 180% + 180% + 180% = 720%

What if we had just done a 4 core and added HT (keeping in the same die space):
100% + 95% +95% +95% + 18% + 18% + 18% + 18% = 457%

What about a 6 core with HT (has to assume more die space):
100% + 95% +95% +95% +95% +95% + 18% + 18% + 18% + 18% + 18% + 18% = 683%

(Spoiler alert - this is a comparison using the same cores, do NOT start saying that there is a 25% performance gain over a 6-core Thuban, which I am sure someone is already starting to type.)

The reality is that by making the architecture modular and by sharing some resources you are able to squeeze more throughput out of the design than if you tried to use independent cores or tried to use HT. In the last example I did not take into consideration that the HT circuitry would have delivered an extra 5% circuitry overhead....

Every design has some degree of tradeoff involved, there is no free lunch. The goal behind BD was to increase core count and get more throughput. Because cores scale better than HT, it's the most predictable way to get there.

When you do the math on die space vs. throughput, you find that adding more cores is the best way to get to higher throughput. Taking a small hit on overall performance but having the extra space for additional cores is a much better tradeoff in my mind.

Nothing I have provided above would allow anyone to make a performance estimate of BD vs. either our current architecture or our compeition, so, everyone please use this as a learning experience and do not try to make a performance estimate, OK?

So based on this we can assume that BD is 90% faster than...
Thanks for the post JF, top notch and very informative as usual!

[flippin_waffles]

Until I see numbers, I'll assume the worse and say it's a 50% decrease. Thats why all of AMD's management is leaving because they know a disaster is looming. I'm being totally sarcastic of course, but you can see what effect the secrecy is having on the general public. Most people I speak to think AMD's next chip is going to be a turd.

Who are you speaking to, people from inetl?

[Musho]

So based on this we can assume that BD is 90% faster than...
Thanks for the post JF, top notch and very informative as usual!

Is it so difficult to see he was merely showing the scaling differences between extra cores, hyperthreading and the way bulldozer does it: Extra cores which share resources inside a module, which saves die space versus extra cores which don't share any resources?

IMO it was a very informative post. Don't forget JF-AMD is under NDA and simply can't give us any performance numbers.