AMD Bulldozer "Zambezi" 32nm "New CPU Architecture" Sockel AM3+ [Part 3]

[Powerplay]

ja bei xs hat der eine ja ausgerechnet das SuperPi normal 14sec brauchen sollte ohne turbo und mit turbo 11sec

[Undertaker 1]

Wo hat das jemand ausgerechnet?

[Mick_Foley]

Hmmm wenn das alles nichts aussagt könnte man sich das Diskutieren generell sparen, bis es eine erste echte Review mit der Launch-Revision gibt.

[Reaper2004]

@Mick_Foley

Also was die Superpibenches angeht, muss ich dem zustimmen. Das führt zu nichts, erst recht nich mit so einer frühen Revision.

[Mondrial]

ja bei xs hat der eine ja ausgerechnet das SuperPi normal 14sec brauchen sollte ohne turbo und mit turbo 11sec

Von was ist der da ausgegangen? Einfach nur die Leistung des Phenom 2 auf den Takt bei 3.8GHz hochgerechnet?

[Reaper2004]

Kann ja nur ne Hochrechnung sein, und selbst den Sinn verstehe ich nicht.
Das einzige was das bringen würde ist, dass man sagen kann das der Superpi Bench keine Aussagekraft hat.

[Undertaker 1]

Von was ist der da ausgegangen? Einfach nur die Leistung des Phenom 2 auf den Takt bei 3.8GHz hochgerechnet?

Das kommt bei weitem nicht hin. Ein 4GHz(!) Phenom II liegt bei etwa 17s.

[Mondrial]

Kann ja nur ne Hochrechnung sein, und selbst den Sinn verstehe ich nicht.
Das einzige was das bringen würde ist, dass man sagen kann das der Superpi Bench keine Aussagekraft hat.

Deswegen frag ich ja. Hab die Tabelle die Powerplay meint auch kurz bei xs gesehen, ich glaub da stand nicht dabei, wie er auf die Werte gekommen ist. Aber bei xs gibts wohl grad Updates...

[Powerplay]

Er meinte das die Cpu bei dem test nur mit 1,8Ghz gelaufen ist auf grund eines bugs!
anhand dieser werte hat er das dann so ausgerechnet das die cpu dann ca 11-14sec brauchen sollte wenn sie ohne den bug rechnen würde was ja auch ein guter wert wäre!

[Mondrial]

Klingt nach Turboproblemen.

Galt das nur für SuperPi? Für 1.8GHz wäre z.B. der Cinebench Wert ziemlich hoch.

[MoggeleMuh]

Sooo hoch fänd ich die 4.6 im Cinebench jetzt auch wieder nicht...
Ein X6 auf 3,3 GHz kommt ungefähr auf 5,9, also etwa 0,98 pro Kern.
Ein BD X8 auf 1,8 GHz käme auf 4,60, also etwa 0,575 pro Kern.
Wenn man mal annimmt dass das linear mit Kernen und Takt skaliert
(was es nicht tut), wäre ein BD auf 3,3 GHZ bei 0,575 * 3,3 / 1,8 = 1,05 pro Kern. Demnach wäre der BD pro Kern etwa 7% schneller als ein X6.

[Techtrancer]

wenn meine mutter eier hätte wär sie mein vater^^

[Mondrial]

Nur das der BD halt keine 8 physischen Kerne hat, wenn man die gemutmaßte maximale Effizienz von CMT mit einrechnet, entspricht es wohl 6.4 oder 7.2 "Kernen".

6,4 Kerne: 1,32 pro Kern bei 3,3GHz(35%)
7,2 Kerne: 1,17 pro Kern bei 3,3GHz(20%)

[Undertaker 1]

Laut JF-AMD sollen das Durchschnittswerte, keine Maximalangaben sein. Warten wir es ab.

[mr.dude]

Glaub ich eher weniger, das war damals auf Pentium1 optimiert. Das Intel da jetzt noch Vorteile von hätte, schließe ich eher aus. Wenns schon PentiumPro gewesen wäre ok, aber so- ne. Der P1 war ja auch noch in-ordern.

1995 war aber bereits der Pentium Pro aktuell. Und die Super Pi Executable stammt ja von 1995. Eine Optimierung auf den P5 macht das Problem für AMD übrigens nicht besser, eher noch schlimmer. Oder anders gesagt, eine Optimierung auf In-Order kommt dem Unified Scheduler von Intel eher zugute. Bei AMDs K8/K10 muss mehr parallel optimiert werden (Loop Unrolling und dergleichen).

Ich denke eher, dass da bei aktuellen Intels der kleine µOp LoopCache zuschlägt, bzw. seit Sandy der dicke µOp Brummer

Sehe ich eher weniger als Ursache. Meist ist Fetch/Prefetch bzw Cache der ausschlaggebende Faktor. Der Pentium-M war hier pro Takt auch schon schneller als K8. Oder schau dir mal Yonah und Merom an, da gibt es nur wenig Unterschied. Und der Loop Detector kam meines Wissens erst mit Merom.

Der Code ist so kompakt und in Schleifen, das dürfte der springende Punkt sein.

Ich habe den Code vor geraumer Zeit mal ein bisschen debugged. So kompakt und in Schleifgen ist der gar nicht. Bzw, wenn ich mich richtig erinnere, wird öfters hin und her gesprungen. Ob das wirklich so gut für einen Loop Detector ist, auch bezüglich Codegrösse, ist fraglich. Neben den bereits von mir genannten Punkten dürfte eine gute Sprungvorhersage eher noch etwas bringen.

SuperPi mit 3.2GHz 3s langsamer als mit 2.8GHz...sagt alles oder?

Der Punkt ist wohl, dass wie schon Bobcat auch Llano und Bulldozer nunmehr einen Referenztakt von 100 MHz besitzen. Zumindest mehren sich die Anzeichen. Die angezeigten 3,2 GHz mit einem Multi von 16 könnten also tatsächlich lediglich 1,6 GHz gewesen sein. Dafür wären knapp 27 Sekunden ziemlich gut.

[MoggeleMuh]

Nur das der BD halt keine 8 physischen Kerne hat, wenn man die gemutmaßte maximale Effizienz von CMT mit einrechnet, entspricht es wohl 6.4 oder 7.2 "Kernen".

6,4 Kerne: 1,32 pro Kern bei 3,3GHz(35%)
7,2 Kerne: 1,17 pro Kern bei 3,3GHz(20%)

Falscher Ansatz. Wenn AMD mir das Teil als 8-Kerner verkaufen will,
und mir das OS auch 8 Kerne anzeigt, dann rechne ich auch mit
8 Kernen um es mit nem X6 zu vergleichen.
Dass ein "Kern" eben nicht mehr ganz so schnell ist, ist dann einfach
in den 7% bereits mit eingerechnet.

[Undertaker 1]

Mal noch ein paar alte Zahlen zu obigem Posting meinerseits:

P3: Hardware news, Overclocking Competitions, Reviews

Thunderbird: Bild: superpitb9pc9.png - abload.de

Wie man sieht, ist der taktbereinigte Unterschied vergleichsweise klein. Die nachfolgenden AMD-Modelle sind in SuperPi einfach nur wenig schneller geworden. Auf 4GHz hochgerechnet liegt der alte Thunderbird auch schon bei ~25s - der Phenom II ist bei gleichem Takt nur etwa 8s schneller.

[mr.dude]

Gut 102 Sekunden bei 1,33 GHz für Thunderbird gegenüber 28 Sekunden bei 2,8 GHz für Regor. Das ist taktbereinigt über 70% mehr Performance. Das soll nur "wenig schneller" sein?

[Opteron]

1995 war aber bereits der Pentium Pro aktuell. Und die Super Pi Executable stammt ja von 1995.

Wir haben jetzt 2011 und AVX ist aktuell, wieviel AVX Programme gibts ?
Abgesehen davon hab ich mich vor ein paar Jahren mal kundig gemacht, es ist P1 optimiert. Was anderes hab ich nie gefunden.

Eine Optimierung auf den P5 macht das Problem für AMD übrigens nicht besser, eher noch schlimmer. Oder anders gesagt, eine Optimierung auf In-Order kommt dem Unified Scheduler von Intel eher zugute. Bei AMDs K8/K10 muss mehr parallel optimiert werden (Loop Unrolling und dergleichen).

Interessant, kannst Du das näher erklären? Dachte das wäre nach dem Dekoder egal, ob jetzt INT Ops in einem Scheduler sind und FP in nem anderen ... da sehe ich auf den ersten Blick eher den Vorteil, dass mit 2 Puffern tieferes OoO möglich ist. Aber erklär mal, im Moment sehe ich keinen Zusammenhang.

Sehe ich eher weniger als Ursache. Meist ist Fetch/Prefetch bzw Cache der ausschlaggebende Faktor.

Hmm kann auch sein, dann müßte der K10 aber stark besser als der K8 sein, da sind ja Fetch/Prefetch und auch Sprungvorhersage deutlich aufpoliert.

Der Pentium-M war hier pro Takt auch schon schneller als K8. Oder schau dir mal Yonah und Merom an, da gibt es nur wenig Unterschied. Und der Loop Detector kam meines Wissens erst mit Merom.

Jein, der Loop Stream Detector gabs erst mit Merom, aber den Loop Detector (Bestandteil der Sprungvorhersage) schon viel länger, seit Dothan / Banias Zeiten. Eventuell macht das am Meisten in dem Fall aus. Ich glaub im realworldtech Artikel vermutete D.Kanter, dass so ein LDetector (nicht der Loop Stream Detecor) auch im BD sein könnte.

Ich habe den Code vor geraumer Zeit mal ein bisschen debugged. So kompakt und in Schleifgen ist der gar nicht. Bzw, wenn ich mich richtig erinnere, wird öfters hin und her gesprungen. Ob das wirklich so gut für einen Loop Detector ist, auch bezüglich Codegrösse, ist fraglich. Neben den bereits von mir genannten Punkten dürfte eine gute Sprungvorhersage eher noch etwas bringen.

Ok einigen wir uns auf den Loop Detecor (nicht den µOp Buffer) mit positiven Auswirkungen auf die Sprungvorhersage ^^

Vielleicht ist auch Memory Disabiguity nicht schlecht, bzw. nur schnelle und/oder große Caches. Wenn ich mich recht erinnere, dann hat doch auch der K10-> K10.5 gut zugelegt. Außer Cache und geringe Zugriffszeit kanns bei dem Schritt ja nicht viel gewesen sein.

Hier ist ne erstbeste Liste:
http://www.radeon3d.org/forum/thread-45.html
Da sieht man, dass die Phenom1 mit 2MB L3 besser sind, als die Ph2 ohne L3, der 940er mit 6MB L3 ist aber deutlich schneller, als der 100Mhz langsamer taktende 7750.

Leider sind keine Prä Conroe Intel Chips in der Liste.

[Undertaker 1]

Für 10 Jahre Entwicklung: Ja. Deswegen doch der Vergleich mit dem Pentum 3, der damals noch auf einem sehr ähnlichen Level lag. Der Leistungssprung späterer Architekturen kam also rein durch deren technische Verbesserungen.

Ok einigen wir uns auf den Loop Detecor (nicht den µOp Buffer) mit positiven Auswirkungen auf die Sprungvorhersage

Genau wie ich oben schrieb.

[classic437]

Also nochmal ganz kurz: 1 Modul hat 2 threads. Wenn nur ein thread gebraucht wird, wie z.b es in Spielen der Fall ist, benutzt der eine thread die kompletten Resourcen des Moduls und dürfte so in der Singlethread Leistung deutlich schneller sein, als wenn sich 2 Threads die Resourcen des einen Moduls teilen müssten, richtig ?
Es geht also nicht nur darum, daß sich im Singlethreadbetrieb nur die Mhz erhöhen, das Modul also hochtaktet, sondern daß der eine Thread nun vollen Zugriff auf die Resourcen des gesamten Moduls hat, oder ?
Das wäre natürlich eine sehr elegante Lösung, nur müssen die Resourcen dann so groß sein, daß es für fast 2 richtige cores reicht, ansonsten würde man ja die Singlethreadleistung eines normalen cores haben und eine halbierte Multithreadleistung, da sich 2 Threads die Resourcen teilen müssten, die eigentlich nur für einen core reichen, wenn man es denn wirklich als 8 Kerner verkaufen will.

Richtig, oder alles falsch ?

Hatte das vorhin bereits in einem anderen Thread gepostet. Hier ist es, glaube ich, besser aufgehoben.

[mr.dude]

Wir haben jetzt 2011 und AVX ist aktuell, wieviel AVX Programme gibts ?
Abgesehen davon hab ich mich vor ein paar Jahren mal kundig gemacht, es ist P1 optimiert. Was anderes hab ich nie gefunden.

Befehlssatzerweiterungen sind ja wieder eine andere Geschichte. Übrigens, AVX wird auch heute schon unterstützt, zB vom GCC. Und wo hast du her, dass Super Pi für den P5 optimiert wäre? Soweit mir bekannt ist, ist der Code des Windows Ports nie veröffentlicht worden. Genauso sind mir Compiler bzw die entsprechenden Build-Flags unbekannt.

Interessant, kannst Du das näher erklären? Dachte das wäre nach dem Dekoder egal, ob jetzt INT Ops in einem Scheduler sind und FP in nem anderen ... da sehe ich auf den ersten Blick eher den Vorteil, dass mit 2 Puffern tieferes OoO möglich ist. Aber erklär mal, im Moment sehe ich keinen Zusammenhang.

Wenn du auf In-Order optimierst, ist es wichtig, die Instruktionen vom Compiler möglichst so ordnen zu lassen, dass sie optimal nacheinander von der jeweiligen Mikroarchitektur abgearbeitet werden können. Neuordnung der Instruktionen im Prozessor selbst fällt ja weg. Dh, die Mikroarchitektur, für die optimiert wurde, steht noch mehr im Fokus als bei OoO. Umso ungünstiger kann der Code für eine komplett andere Mikroarchitektur sein. Mit einem Unified Scheduler hast du nun den Vorteil, die MicroOps kompromisslos so zu verteilen, wie sie gerade kommen. Bei dedizierten Schedulern muss hingegen das Verhältnis stimmen, damit alle Einheiten möglichst gleichmässig ausgelastet werden. Und bei ungünstigem Code kann das ein Nachteil sein, wenn das Verhältnis nicht mehr passt.

Hmm kann auch sein, dann müßte der K10 aber stark besser als der K8 sein, da sind ja Fetch/Prefetch und auch Sprungvorhersage deutlich aufpoliert.

Deutlich ist relativ. Von K8 zu K10.5 waren es aber zumindest 20-25%, IIRC. So wenig ist das nicht.

Jein, der Loop Stream Detector gabs erst mit Merom, aber den Loop Detector (Bestandteil der Sprungvorhersage) schon viel länger, seit Dothan / Banias Zeiten. Eventuell macht das am Meisten in dem Fall aus. Ich glaub im realworldtech Artikel vermutete D.Kanter, dass so ein LDetector (nicht der Loop Stream Detecor) auch im BD sein könnte.

Und was macht der Loop Detector dann konkret, also nicht Loop Stream Detector?

Also nochmal ganz kurz: 1 Modul hat 2 threads. Wenn nur ein thread gebraucht wird, wie z.b es in Spielen der Fall ist, benutzt der eine thread die kompletten Resourcen des Moduls und dürfte so in der Singlethread Leistung deutlich schneller sein, als wenn sich 2 Threads die Resourcen des einen Moduls teilen müssten, richtig ?
Es geht also nicht nur darum, daß sich im Singlethreadbetrieb nur die Mhz erhöhen, das Modul also hochtaktet, sondern daß der eine Thread nun vollen Zugriff auf die Resourcen des gesamten Moduls hat, oder ?

Korrekt. Zumindest auf die Ressourcen, die sich zwei Threads ansonsten teilen müssen, wie L1I, L2, Frontend oder FPU. Ob ein Thread nun deutlich schneller ist, wird sich noch zeigen müssen. Er sollte aber auf jeden Fall schneller sein.

[Schaffe89]

Korrekt.

Dass das funktioniert ist überhaupt nicht gesichert.
Sonst müssten ja bei 4 Threads auch 4 Module arbeiten und je Thread nur eine Integer Ausführungseinheit.

[Undertaker 1]

Da gibts doch gar nicht viel zu überlegen. Wenn ein Modul 180/160% Leistung bei zwei Threads liefern soll (100% bei einem Thread), ist die pro-Thread Leistung bei nur einem Thread 11/25% höher. Das ist allerdings eine komische Rechnung, wenn man selbige für SMT mit 20% Speedup durchführt, steigt dort die Leistung bei nur einem Thread um ganze 67%...

Ich würde mich sinnvollerweise auf die Angabe des Speedups durch den zweiten Thread beschränken.

[Opteron]

Befehlssatzerweiterungen sind ja wieder eine andere Geschichte.

Sehe ich jetzt nicht so, unten erklärst Du ja selbst, was schief geht, wenn InO Code auf OoO läuft. Der Schritt von InO- >OoO ist ja noch komplexer als ne kleine Befehlssatzerweiterung.

Übrigens, AVX wird auch heute schon unterstützt, zB vom GCC.

Ja, Compiler sind immer die ersten, aber SuperPi ist ne Applikation, kein Compiler. Und Applikationen gibts meines Wissens nur den Sandra Bench.

Und wo hast du her, dass Super Pi für den P5 optimiert wäre? Soweit mir bekannt ist, ist der Code des Windows Ports nie veröffentlicht worden. Genauso sind mir Compiler bzw die entsprechenden Build-Flags unbekannt.

Hatte ich vor Jahr und Tag gesucht und gefunden, Compiler war irgendein alter Fortran / Watcom oder wie die Firma hieß. Machen wirs doch mal anders herum, such mal nen Compiler, den es Anno 1995 gab, der mit PentiumPro Optimierung warb. Ich hab nichts gefunden, aber vielleicht hast Du mehr Glück ;-)

Wenn du auf In-Order optimierst, ist es wichtig, die Instruktionen vom Compiler möglichst so ordnen zu lassen, dass sie optimal nacheinander von der jeweiligen Mikroarchitektur abgearbeitet werden können.

Glasklar.

Neuordnung der Instruktionen im Prozessor selbst fällt ja weg. Dh, die Mikroarchitektur, für die optimiert wurde, steht noch mehr im Fokus als bei OoO.

Auch ok.

Umso ungünstiger kann der Code für eine komplett andere Mikroarchitektur sein.

Hmm wieso ? Mit OoO kann die doch die Befehle schön so orden wie es der Architektur dann passt. Oder meinst Du, dass die OoO Fenster dazu zu klein sind ?

Mit einem Unified Scheduler hast du nun den Vorteil, die MicroOps kompromisslos so zu verteilen, wie sie gerade kommen. Bei dedizierten Schedulern muss hingegen das Verhältnis stimmen, damit alle Einheiten möglichst gleichmässig ausgelastet werden.

Ist das nicht das gleiche? Zwischen AMD und Intel gibts doch nur den Unterschied, dass bei AMD die Ops halt vorher in einen INT und FP Scheduler aufgesplittet werden. Danach werden die genauso "kompromisslos" verteilt. Eine FP Op im unified decoder hat ja nichts davon, wenn ein INT Port frei ist.
Ich sehe einen getrennten FP/INT scheduler eher als VOrteil, da können sich die FP/INT Ops nicht die Warteplätze wegnehmen. Insgesamt sollte damit dann doch besseres/tiefers OoO möglich sein. Wie siehst Du das ?

Deutlich ist relativ. Von K8 zu K10.5 waren es aber zumindest 20-25%, IIRC. So wenig ist das nicht.

Aufpassen, ich fragte von K8-> K10, nicht auf K10.5. Den K10-> K10.5 Schritt hatte ich doch auch schon beschrieben, da scheint ne Menge auf das Konto des L3 Caches zu gehen. Eventuell ist das wirklich das Wichtigeste bei SuperPi.

Und was macht der Loop Detector dann konkret, also nicht Loop Stream Detector?

Das:

The Loop Detector (Figure 2) analyzes branches to see if
they have loop behavior. Loop behavior is defined as
moving in one direction (taken or not-taken) a fixed
number of times interspersed with a single movement in
the opposite direction. When such a branch is detected,
a set of counters are allocated in the predictor such that
the behavior of the program can be predicted completely
accurately for larger iteration counts than typically
captured by global or local history predictors.

http://www.intel.com/technology/itj/...iss2_art03.pdf

Grund:

A predictor that always branches in a loop will always incorrectly branch on the last iteration

http://www.cs.virginia.edu/~skadron/cs451/PentiumM/IntelPentiumM_r4.ppt (S. 40/41)


Aaaber:
So toll waren die Pentium M auch nicht, hab ein paar alte Screens ausgegraben:
24,5s für nen 3GHz Dothan:
http://www.abload.de/img/attachmentf8iv.jpg

27s für nen 3,05 Ghz AMD 3700+:
http://www.abload.de/img/attachmentu8a5.jpg

Nur leicht besser als ein K8, ein K10 dürfte in etwa auf gleichem Niveau sein.

Am Ende bleibt dann der dicke 4MB Cache und Memory Disambiguity des Conroe übrig.

Cache hat BD ohne Ende und MDis. wahrscheinlich auch, wenns Bobcat schon hat...
Apropos .. wie schlägt sich Bobcat bei SuperPi ... ?Mal googlen. Auf einer Seite MDis, auf der anderen Seite ne Spar-FPU, geht wohl trotzdem in die Hose.
Edit:
Ja, Zacate @1,6Ghz ~140s, ein Ph2@1,6Ghz nur ~41s. Lol.
http://www.pureoverclock.com/review.php?id=895&page=5

Und um wieder den Bogen zurück zu schaffen:
Laut AIDA gibts irngedwelche L2/L3 Probleme mit den BD-B0 Teilen, dafür wären dann die SuperPi Werte eher gut, da Spi anscheinend ja recht Cache-lastig ist. Von daher würde ich im Moment da nicht viel drauf geben ;-)