Bulldozer rollt an....

[SPawner]

JF hat doch im XS Forum gesagt, dass bei der CeBIT nixs neues (von Bulldozer) Veröffentlicht wird. Also nur nochmal Zeugs von der ICCSS oder sowas in der Art.

 

[ONH]

@BR

3,5Ghz für einen 16-Core Interlagos halte ich für ausgeschlossen, selbst für die TDP=140Watt-Version, denn 140Watt/16=8,75Watt; und darin wäre auch noch der Uncore enthalten, sodass dann ein Core @3,5Ghz nur noch rund 8Watt hätte. Und ich bezweifle sehr, dass AMD demnächst einen 1Modul-BD mit einer TDP=18Watt mit 3,5Ghz auspacken kann.

Da hast du ganz recht, wie hier vor ein paar Wochen Verlinkt war, wird ein Supercomputer mit 12Core@2,1GHz auf 8Modul@2.3GHz Server CPU aktualisiert ohen die Kühlung zu ändern, somit ergibt sich für ein Modul@2.3GHz eine TDP von 14W.

 

[gruffi]

Beispiel:
Man denke sich zwei Tierchen - eins mit sechs und eins mit vier Beinchen.
Beide rennen los zum Kaese an der Tischkante - das sechsbeinige Tier ist als erster am Kaese und gewinnt.

Nun werden beide Tiere von der 'machmirnureinBein-Seuche' befallen und verlieren alle Beine bis aus jeweils eins.
Nun liegt wieder eine Stueck Kaese und eine Aspirin an der Tischkante - beide humplen wieder von gleichen Stelle wie zuvor los.
Wer wird die Kopf- und Gliederschmerzen als erst los? Ja, richtig der Ex-Vierbeiner.

Warum? Sein verbliebendes Bein war staerker als eins des Ex-Sechsbeiners - ausserdem war er etwas kleiner und hatte weniger zu tragen.
Auch wenn im normalen Leben der Sechsbeiner immer gewonnen haette - gibt es Situationen, in denen er auch verliert. Das Einzelbein des Sechsbeiners ist verglichen mit einem Einzelbein des Vierbeiners eben schwaecher.

Du schreibst schon wieder solches wirres Zeug wie gestern. Ohne Vergleichsbasis lässt sich überhaupt nichts über ein Einzelbein oder eben einen Kern bzw logischen Prozessor herleiten.

Man denke sich ein Tier mit sechs Beinen - nur weil es mit sechs Beinchen schnell ist - heisst es nicht, dass es auch noch mit einem noch waere.

Und genauso wenig heisst das, dass es mit nur einem Beinchen langsam wäre.

 

[LoRDxRaVeN]

Im Moment sehe ich das Thema Singlethreadperformance (aus meiner prozessortechnisch beschränkten Sicht) so:

Das einzige, was BD als "besondere Eigenschaft" können muss, damit er hohe Singlethreadperformance erreicht, ist, dass ein Integerkern = alle non-shared Komponenten) hoch takten kann (im Idealfall knapp doppelt so hoch als im Multithreading-Betrieb). Alle shared-Komponenten sind ja sowieso weit überdimensioniert (wenn sie nur einen Thread bedienen müssen) und das thermische (bzw. hald Strom-) Budget ist durch Clock- und Powergating der anderen, nicht verwendeten Module ja sowieso mehr als groß genug.
Also nur ein verhältnissmäßig kleiner Teil des Siliziums bzw. der Transistoren muss sehr hoch taktbar sein. Von der längeren Pipe, welche dies begünstigen würde, haben wir schon gehört - damit diese keine (oder nur geringe) Nachteile hat, gibt es diverse Gegenmaßnahmen.
Und das verhältnismäßig hohe Takte siliziumtechnisch machbar sind, sieht man z.B. bei IBM...

An die Leute die sich mit der Materie auskennen: Ist es technisch überhaupt machbar, dass ein (so wie vorhin definierter) Integerkern um einiges höher taktet, als der Rest des Moduls (also die shared-Komponenten)?

Wenn dies (so ähnlich) möglich ist, wie ich mir das vorstelle, könnte BD sehrwohl sehr hohe Singlethreadperformance bieten

LG

 

[gruffi]

Ich sehe ehrlich gesagt nicht, dass man einen sehr hohen Takt braucht. Ein Bild sagt manchmal mehr als tausend Worte. Man vergleiche einfach mal die Dimensionierung des alten und des neuen Integer Clusters.

Wenn AMD solche Folien rausgibt und ein Integer Cluster pro Takt weniger leistet als der alte, dann hätte man definitiv was falsch gemacht, entweder in der Entwicklungs- oder Marketingabteilung.

 

[aylano]

Wenn AMD solche Folien rausgibt und ein Integer Cluster pro Takt weniger leistet als der alte, dann hätte man definitiv was falsch gemacht, entweder in der Entwicklungs- oder Marketingabteilung.

Solche Sprüche wären aber von der Marketing-Abteilung in Ordnung.

Wenn ein BD-Modul im selben Takt nur 90-95% eines K10-Dual-Core leistet, aber nur 80% Stromverbraucht, dann können sie immer noch den Takt erhöhen und bei gleichem Stromverbrauch schneller zu sein.

Wenn du dich verarscht fühlst, dann bitte, aber die Aufgabe der Marketing-Abteilung ist nun mal, ihr Produkt im besserem Licht darzustellen.

PS: Ich hatte jetzt nur deinen Beitrag gelesen und die Vorigen nicht.

 

[Stryki]

Dazu könnte man die Bobcat 90% Mainstream CPU Folie verlinken. Letztlich ist es relativ sinnlos weil zu allem eine verlässliche Basis fehlt. Keiner außer AMD weiß was die Basis für die Vergleiche ist oder ob man einfach dem Powerpointpraktikanten gesagt hat: Mach das mal so ist grob unsere Vorstellung dabei.

 

[nazgul99]

Hmmm ...

in der nächsten c't 7/2011 (Abonnenten: 12.3., Kiosk: 14.3.) werden unter dem Titel "Mainboards für Phenom und Core i7" AM3-Mainboards gegen LGA1366-Mainboards antreten. Nun überschneiden sich aber die Preise für LGA1366-CPUs (mindestens €220) und AM3-CPUs (bis knapp €200) nicht. So ein Vergleich wäre eigentlich grenzwertig bis blödsinnig - obere Mittelklasse vs. Highend? Soll uns das vielleicht etwas sagen und es wurde an einer bestimmten Stelle ein winziges "+" weggelassen?

Im gleichen Heft wird es einen CPU-Wegweiser ("Athlon, Phenom oder Turion, Core i7, i5, i3 oder Core 2 Duo [...]") geben, soso ... Und - Achtung modern: "Ein Überblick über aktuelle Desktop-, Mobil- und Handy-Prozessoren".

 

[Stryki]

Es gibt Themen die immer jedes Jahr in der gleichen Ausgabe kommen. Wie zu Weihnachten das typische mein Komplettrechner geht nicht ABC usw.
Ich wette Bulldozer wird kurz erwähnt mehr aber auch nicht, erst recht nicht wenn wirklich nichts zur Cebit kommt.

 

[Markus Everson]

Im Moment sehe ich das Thema Singlethreadperformance (aus meiner prozessortechnisch beschränkten Sicht) so:

Das einzige, was BD als "besondere Eigenschaft" können muss, damit er hohe Singlethreadperformance erreicht, ist, dass ein Integerkern = alle non-shared Komponenten) hoch takten kann

Könntest Du das bitte nochmal wiederholen? Ich konnte Dich nicht vollständig verstehen weil irgendwo in meinem Kopf ständig eine Stimme "PentiumIV" brüllt...

 

[LoRDxRaVeN]

Ich sehe ehrlich gesagt nicht, dass man einen sehr hohen Takt braucht.

"Brauchen" ist natürlich relativ. Denn ich bin ja auch der Meinung (wie andere hier), dass hohe Singlethreadleistung in der Praxis nur selten tatsächlich benötigt wird.
Aber zumindest könnte man es als hervorragendes Marketingmittel heranziehen. (So sehe ich schon den aktuellen Thuban-Turbo: Ein Marketingmittel, dass man braucht)
Und so wie ich es beschrieben habe, wäre der hohe Takt hald die Vorraussetzung bzw. eine Möglichkeit die sowieso vorhandenen (shared) Ressourcen (aus)zu nützen.

LG

 

[WindHund]

Ich nehme mal stark an, dass der L2 mit fullspeed läuft. Da der dicke 2MB hat, müssen die 8MB L3 nicht mit voller Geschwindigkeit laufen. Intel hat durch den kleinen 0,25MB L2 viel mehr L2 <> L3 Traffic, erst recht wenn da 2 Threads laufen. Deswegen bekamen sie mit Sandy auch nen schönen IPC Nachschlag, nachdem der L3@Fullspeed läuft.

lol, hab mich schon gewundert warum bei CPUz der uncore (Northbridge) Takt bei der RAM Anzeige fehlt, bei der Sandy Bridge CPU.
Aha, dann bin ich mal gespannt inwiefern sich das beim Bulli auswirkt mit dem höheren NB-Takt.
Was ist denn der aktuelle Stand dabei, hab noch 2,4GHz+ im Hinterkopf.

MfG

 

[Duplex]

Was ist denn der aktuelle Stand dabei, hab noch 2,4GHz+ im Hinterkopf.

genau +20% mehr als K10.5

 

[WindHund]

genau +20% mehr als K10.5

Mehr Leistung oder mehr Takt? (Quelle?)

 

[Duplex]

mehr Northbridge Takt, du hast doch gefragt wieviel Ghz die 2,4 sind richtig

 

[Opteron]

Ich sehe ehrlich gesagt nicht, dass man einen sehr hohen Takt braucht. Ein Bild sagt manchmal mehr als tausend Worte. Man vergleiche einfach mal die Dimensionierung des alten und des neuen Integer Clusters.

<Bild>

Wenn AMD solche Folien rausgibt und ein Integer Cluster pro Takt weniger leistet als der alte, dann hätte man definitiv was falsch gemacht, entweder in der Entwicklungs- oder Marketingabteilung.

Naja, JF AMD erzählt zum Bildchen das Mär von den 3AGU/ALU Pärchen, was bekanntermaßen Käse ist.
Ab gesehen davon hat ein MC keine FMAC FPU, den Fehler gibt er aber immerhin zu.
AM Ende ist die Glaubwürdigkeit des Bildchens aber ziemlich angeknackst ..

 

[LoRDxRaVeN]

Ich konnte Dich nicht vollständig verstehen weil irgendwo in meinem Kopf ständig eine Stimme "PentiumIV" brüllt...

Wie gesagt ist mein technisches Verständnis auf das Thema bezogen beschränkt.
Argumente die ich aber trotzdem aufzählen bzw. wiederholen kann:

- völlig andere Bedingungen/Voraussetzungen (130/90nm vs. 32nm mit diversen, zusätzlichen "Eigenschaften")
- "längere Pipe" ist nicht gleichbedeutet mit "gleich oder ähnlich lange, wie die vom P4"
- auch etwas andere Gründe, weshalb man hohen Takt als Lösung einsetzen will (nur ein kleiner Teil muss hoch getaktet werden und auch nur für den Singlethreadfall)

Leg' das alles bitte nicht auf die Goldwaage, denn das ist ja nur meine Vorstellung von der Sache...

LG

 

[gruffi]

Naja, JF AMD erzählt zum Bildchen das Mär von den 3AGU/ALU Pärchen, was bekanntermaßen Käse ist.

Begründung?

 

[bbott]

Begründung?

Weil in der Grafik so weit ich das sehe/verstanden habe beim Magny Cours eine Pipline für ein AGU und ALU steht, also ein Pärchen. Zusammen also 6 Recheneinheiten ergeben.
Beim Bulldozer stehen zwei Pipelines für AGU und zwei für ALU, wobei diese nicht 1:1 Vergleichbar sind weil sie etwas mehr können.

Das reale Verhältnis ist etwa Magny Cours 6:4 Bulldozer, im Bild ist es ein 3:4 Verhältnis.

Deswegen gingen anfangs nach Veröffentlichung des Bildes auch viele davon aus, dass es 4 AGUs und 4 ALUs wären.

 

[Dresdenboy]

Ich glaube, das Problem, die ALUs/AGUs zu verstehen, ist die fehlende genaue Doku. Ich sah auch erst im CodeAnalyst Pipeline Simulator, dass bei einem Int-Befehl mit Mem-Operand nicht 2mal issued wird, sondern halt der längere "Pipeline-Weg" (vereinfacht) issue - agu - data cache - data cache - exu verwendet wird. Das heißt aber auch, dass das ein relativ starres Schema ist. So ein Befehl kann m.W. praktisch nur ausgeführt werden, wenn schon zum Beginn der Adressberechnung alle Operanden bereit sind. BD sollte dagegen unabhängig schonmal die Speicheradresse berechnen und die Daten aus dem Cache holen können.

 

[gruffi]

Weil in der Grafik so weit ich das sehe/verstanden habe beim Magny Cours eine Pipline für ein AGU und ALU steht, also ein Pärchen. Zusammen also 6 Recheneinheiten ergeben.
Beim Bulldozer stehen zwei Pipelines für AGU und zwei für ALU, wobei diese nicht 1:1 Vergleichbar sind weil sie etwas mehr können.

Das reale Verhältnis ist etwa Magny Cours 6:4 Bulldozer, im Bild ist es ein 3:4 Verhältnis.

Deswegen ist die Darstellung doch aber nicht falsch. Aus dem Bild geht überhaupt nicht hervor, wie viele Ausführungseinheiten vorhanden sind. Wenn ich mal aus dem Software Optimization Guide für 10h zitieren darf:

The integer execution pipeline consists of three identical pipes (0, 1, and 2). Each integer pipe consists of an arithmetic-logic unit (ALU) and an address generation unit (AGU).

Und genau diese 3 Pipes sind auch bei Magny Cours visualisiert. Bulldozer hat nun eine Pipe mehr, eben 4. Inwiefern Pipes und Ausführungseinheiten zwischen Bulldozer und K10 vergleichbar sind, ist wiederum ein anderes Thema und bisher noch unklar.

 

[TNT]

Du schreibst schon wieder solches wirres Zeug wie gestern. Ohne Vergleichsbasis lässt sich überhaupt nichts über ein Einzelbein oder eben einen Kern bzw logischen Prozessor herleiten.


Und genauso wenig heisst das, dass es mit nur einem Beinchen langsam wäre.

Ich kann nicht mehr helfen und gebe auf.

 

[bbott]

Und genau diese 3 Pipes sind auch bei Magny Cours visualisiert. Bulldozer hat nun eine Pipe mehr, eben 4. Inwiefern Pipes und Ausführungseinheiten zwischen Bulldozer und K10 vergleichbar sind, ist wiederum ein anderes Thema und bisher noch unklar.

Sollte Bulldozer nicht 2 AGU und 2 ALUs bekommen?!

 

[Opteron]

Und genau diese 3 Pipes sind auch bei Magny Cours visualisiert. Bulldozer hat nun eine Pipe mehr, eben 4. Inwiefern Pipes und Ausführungseinheiten zwischen Bulldozer und K10 vergleichbar sind, ist wiederum ein anderes Thema und bisher noch unklar.

Da ist mal wieder ein Verständnisfehler (nicht von Dir, sondern allgemein) zw. Pipeline und Unit. Wo ist da der Unterschied ? Gibts nicht, Unit ist nur der funktionale Begriff, Pipeline der technische. ALU und AGU sind trotz der "Unit" Bezeichnung immer noch Pipelines.

K10 konnte mit den 3 Pipelinepärchen/Units oder was auch immer pro Takt 3 AGU Ops und 3 ALU Ops losschicken. BD kann aber nur je 2.

Die Illustration ist dann einigermaßen ok, wenn man hervorheben will, das die 2 ALU und 2 AGUs nicht mehr starr gekoppelt sind. AGU2 kann auch Adressen für ALU1 berechnen, das ging vorher nicht. Aber im theoretischen Maximum kommt man trotzdem nicht am Durchsatz des MCs heran. Aber naja - darin liegt wohl auch der Hase im Pfeffer, gab ja die andere Aussage, dass das 3te Pärchen nur ~5%+ schaffte. Da die IPC insgesamt steigen wird, wollte AMD da wohl visualisieren, dass die Pipelines des BDs schneller werden, und hat sich gedacht, dass das ne gute Idee wäre, wenn sie da 4 ins Bild klatschen. Für die "Finanzexperten" sicherlich ein probates Mittel, aber jedem Ingenieur stellen sich die Nackenhaare zu Berge.
Aussnahme: Die neuen AGUs können wirklich mehr, als die alten. Aber danach schauts im Moment nicht aus.

@Dresdenboy:
Hm, das ist doch der normale Ablauf, oder nicht? Bevor der ALU Befehl mit MemOp loslegen kann, braucht er erstmal seine Speicheradresse, d.h. die ALU µOp warten erstmal im Scheduler, bis die AGU µOp fertig ist. Durchsatz kann trotzdem 2 µOps pro Takt sein, da die beiden µOps ja nicht aus der gleichen MacroOp stammen müssen.

 

[mocad_tom]

Am richtigsten(wenn es das gibt) ist man wohl wenn man es als Issue-Wide bezeichnet.

Ein BD-Integer-Core wird wohl 2-Issue-Wide sein. K10.5 war noch 3 Issue-Wide.
Nehalem ist 4-Issue-Wide.

DDB hat gestern noch eine Erklärung von Fruehe gefunden und bei Twitter gepostet:

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?

Ein haufen Holz.
Damit wollte er die 180% Zahl erklären.
mMn dreht sich die ganze Diskussion ziemlich im Kreis.
Die einzigen wirklich verlässlichen Zahlen sind die von dem Supercomputer - und das klingt Okay aber nicht umwerfend.