[Sammelthread] 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/2003/volume07issue02/art03_pentiumm/vol7iss2_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 ;-)

 

[neuli]

Wir haben jetzt 2011 und AVX ist aktuell, wieviel AVX Programme gibts ?

Als gentoo User sag ich unzählige, denn der gcc unterstützt avx und damit kann jedes open source Programm mit avx umgehen. Ob es davon auch profitiert ist eine andere Geschichte. Siehe auch:
[Phoronix] GCC 4.6 Compiler Performance With AVX On Sandy Bridge

 

[y33H@]

Und Applikationen gibts meines Wissens nur den Sandra Bench.

Sisoft 2011, AIDA64 und Linpack sind mir derzeit bekannt. Ist halt alles eher theoretisch.

 

[mr.dude]

Ja, Compiler sind immer die ersten, aber SuperPi ist ne Applikation, kein Compiler.

Dir ist aber schon klar, dass der Compiler den Quellcode übersetzt und die Executable erstellt (Linker)?

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

1995 erschien Watcom 10.5. Warum soll der noch keine Pentium Pro Optimierungen gehabt haben? Aber wie gesagt, ohne Compiler (Version) und konkreten Flags bringt uns das Rätselraten nicht weiter.

Hmm wieso ? Mit OoO kann die doch die Befehle schön so orden wie es der Architektur dann passt.

Aber nur bis zu einem gewissen Grad. Wenn man alles im Prozessor neu ordnen könnte, so wie man es braucht, warum gibt es bei Compilern überhaupt noch Optimierungsflags für Mikroarchitekturen?

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.

Nee, K8/K10 hat einen Scheduler für FP und jeweils einen Scheduler für jede Int Pipe. Also 4 Scheduler für einen Kern insgesamt. Intel hat lediglich einen Scheduler für alles.

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 ?

Beispiel, in jedem Takt kommen 50% Int, 50% FP MicroOps. Was macht der Intel Scheduler? Er schickt die MicroOps an die EUs, so wie sie am besten passen. Int und FP EUs befinden sich ja teils an den selben Ports. Was machen die AMD Scheduler hingegen? 50% der MicroOps (Int) müssen von 6 EUs verarbeitet werden (3x ALU/AGU), während die anderen 50% der MicroOps (FP) von lediglich 3 EUs verarbeitet werden müssen (FADD/FMUL/FMISC). Oder etwas überspitzt formuliert, während die FP EUs schwitzen, drehen die Int EUs Däumchen. Du kannst das Beispiel natürlich auch umdrehen, indem du 90% Int und 10% FP MicroOps nimmst. Wie auch immer. Im Grunde ist die AMD Lösung "sauberer". So ermöglicht sie auch das CMT Design bei Bulldozer mit einer geteilten FPU und separaten Integer Clustern. Nur benötigt sie eben auch mehr Optimierungsarbeit.

Das: http://www.intel.com/technology/itj/2003/volume07issue02/art03_pentiumm/vol7iss2_art03.pdf

Ja, dann geht es hier wirklich nur um Sprungvorhersage. Wie gesagt, das könnte bei Super Pi schon eher eine Rolle spielen als der Loop Stream Detector.

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

Lustig ist, Intel schreibt, dass es den Loop Detector seit dem P6 gibt. Fragt sich nur, was später verbessert wurde. Von Pentium-M zu Core (Yonah) gab es scheinbar einen ordentlichen Sprung in Super Pi.

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.
AMD Athlon II X3 440, X4 635, and Phenom II X4 910e

Nee, Bobcat soll bei ~48 Sekunden (1M) liegen. Woher die hohen Werte kommen? Vielleicht wieder irgendwelche verkrüppelten Samples? Etwas weniger als 50 Sekunden für 1,6 GHz ist jedenfalls ziemlich gut. Das ist vergleichbare Taktperformance zu meinem X2 240. Sicherlich bremst die halbierte FPU bei Bobcat nicht, ist ja eh nur x87. Dennoch, für ein so kompaktes 2-fach OoO Design, mit einem Speicherdurchsatz der knapp über der Grasnarbe liegt, beachtlich. Da hat man intern offenbar ordentlich optimiert. Das lässt für Bulldozer hoffen.

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.

Ist zwar 'ne schöne Theorie, halte ich aber nicht für sonderlich wahrscheinlich. In der Vergangenheit hat dieser Test auch schon mal Nullnummern angezeigt, weil er bestimmte Prozessoren noch nicht kannte. Ich sehe momentan eigentlich nur zwei Probleme, Fakes und falsch berechneter Takt (Multi).

 

[Opteron]

Dir ist aber schon klar, dass der Compiler den Quellcode übersetzt und die Executable erstellt (Linker)?

Klar. Was ich meinte ist, dass es ne Zeit dauert, bis sich neue Compiler verbreiten und überhaupt benützt werden. Bei nem Mini-"Witz" Freizeitprogramm könnte man vielleicht doch gemacht haben, aber da spricht nichts dafür.

1995 erschien Watcom 10.5. Warum soll der noch keine Pentium Pro Optimierungen gehabt haben? Aber wie gesagt, ohne Compiler (Version) und konkreten Flags bringt uns das Rätselraten nicht weiter.

Weil es - im Gegensatz zur Pentium Optimierung bei 9.5 - nicht in der Featureliste erwähnt wird:

Watcom C 9.5/386

• C++ compiler added
• Pentium optimizations
• Windows NT host and target support

[edit]
Watcom C/C++ 10.0

• 16-bit and 32-bit tools merged into single package
• Graphical IDE for Windows and OS/2
• Redesigned debugger
• C++ class browser added
• Precompiled header support
• Windows resource editors added
• MFC included

[edit]
Watcom C/C++ 10.5

• Windows 95 and NT 3.5 support
• Native C++ exception handling on OS/2 and Win32
• TCP/IP remote debugging

History - Open Watcom

Aber nur bis zu einem gewissen Grad. Wenn man alles im Prozessor neu ordnen könnte, so wie man es braucht, warum gibt es bei Compilern überhaupt noch Optimierungsflags für Mikroarchitekturen?

Ja ok, das meinte ich mit der Tiefe, gibt ja keine grenzenlosen Reservation Stations bei OoO. Also meinst Du, dass die aktuellen Puffer nicht tief genug sind, um schlechten InO Code "richtig" zu ordnen. Hmm, wäre mal interessant das auszutesten, gibt bei den Intel Compilern ja jetzt auch Atom als Targetplattform, wäre interessant, wie unterschiedlich das am Ende zu nem normalen SSE3 Compilat wäre.

Nee, K8/K10 hat einen Scheduler für FP und jeweils einen Scheduler für jede Int Pipe. Also 4 Scheduler für einen Kern insgesamt. Intel hat lediglich einen Scheduler für alles.

Aaah, Du meinst die 3 INT Scheduler, sags doch gleich

Beispiel, in jedem Takt kommen 50% Int, 50% FP MicroOps. Was macht der Intel Scheduler? Er schickt die MicroOps an die EUs, so wie sie am besten passen. Int und FP EUs befinden sich ja teils an den selben Ports. Was machen die AMD Scheduler hingegen? 50% der MicroOps (Int) müssen von 6 EUs verarbeitet werden (3x ALU/AGU), während die anderen 50% der MicroOps (FP) von lediglich 3 EUs verarbeitet werden müssen (FADD/FMUL/FMISC). Oder etwas überspitzt formuliert, während die FP EUs schwitzen, drehen die Int EUs Däumchen. Du kannst das Beispiel natürlich auch umdrehen, indem du 90% Int und 10% FP MicroOps nimmst. Wie auch immer. Im Grunde ist die AMD Lösung "sauberer". So ermöglicht sie auch das CMT Design bei Bulldozer mit einer geteilten FPU und separaten Integer Clustern. Nur benötigt sie eben auch mehr Optimierungsarbeit.

Ok, verstanden was Du meinst. Pro AMD kann man noch anmerken, dass die 3 FP Scheduler pro Lane mehr Einträge haben, als die INT, und INT+FP zusammen mehr Einträge haben als Intel. Aber das nützt halt nicht, da AMD damit bei FP pro Lane nur max 14 Befehle umsortieren kann, Intel dagegen 36 (Nehalem) bzw. jetzt 54 (Sandy). Wie man sieht klotzt Intel da bei Sandy richtig ran, und AMD steht beim Bulldozer mit 40INT(pro Cluster)+60FP auch nicht hinten dran. Schon interessant, wie sich das Ganze entwickelt. Da macht AMD nen großen Schritt zu mehr OoO Fähigkeit.

Ja, dann geht es hier wirklich nur um Sprungvorhersage. Wie gesagt, das könnte bei Super Pi schon eher eine Rolle spielen als der Loop Stream Detector.

Hm, ja aber was sagst Du dann zum mäßigen Dothan Ergebnis? Ist ja nicht soo der Bringer.

Lustig ist, Intel schreibt, dass es den Loop Detector seit dem P6 gibt.

Echt, wo ? Kann mich noch daran erinnern, das D.Kanter auch gemeint hat, dass Intel das erst seit den P-Ms hat.

Fragt sich nur, was später verbessert wurde. Von Pentium-M zu Core (Yonah) gab es scheinbar einen ordentlichen Sprung in Super Pi.

Hm, aber wieso ? Dachte erst, dass sich da nicht viel tuen würde, Yonah ist doch nur ein dual Dothan in 65nm mit unified Cache. Aber SuperPi legt da wirklich gut zu. Hab hier praktischerweise nen Dothan <> Yonah Test gefunden:

[M] Battle of the Mobile CPUs: Core Duo vs Pentium M

Was passiert da bloß .. strange, selbst die Cachegröße ist gleich.
Edit:
Yonah ist doch mehr als 2xDothan, Insgesamt ist wohl "Intel's Digital Media Boost" daran schuld ... nur blöd das man nicht soviele Details findet, hier 2:

Intel stattet Yonah mit der "Digital Media Boost" getauften Technologie aus. Dabei erweitert der Hersteller die MicroOps-Fusion des Pentium M auf die SSE2-Instruktionen. Die MicroOps-Fusion-Technologie analysiert die Instruktionen des Programmablaufs. Wenn sich mehrere Operationen zusammenfassen lassen, werden sie zu einem neuen Befehl verschmolzen. Yonah nutzt für die SSE2-Instruktionen zudem alle drei Decoder-Einheiten.
Zusätzlich erhält Yonah zehn SSE3-Befehle: fünf für komplexe Arithmetik, einen für Video-Encoding und vier für grafiklastige Operationen. Die Floating-Point-Performance verbessert Intel außerdem durch ein erweitertes Data Prefetching und zusätzliche Write Output Buffers.

http://www.tecchannel.de/pc_mobile/...ino_2006_dual_core_fuer_notebooks/index6.html

Er bietet im Vergleich zu Dothan nicht nur einen zweiten Kern, sondern auch etliche Architekturverbesserungen. So wurde die SSE/SSE2-Einheit beschleunigt, ebenso die FPU und die Division per IDIV-Befehl. Die Dekoder sind deutlich schneller geworden, die Mikrooperationen mächtiger und SSE3 sowie Virtualisierung (VT) sind hinzugekommen. Einige dieser Verbesserungen fasst Intel unter dem Namen "Digital Media Boost" zusammen. 64-Bit-Unterstützung (EM64T) hat der Prozessor indes noch nicht, das bleibt seinem Nachfolger Merom vorbehalten.

http://www.heise.de/newsticker/meldung/IDF-Vor-Merom-kommen-Yonah-und-Sossaman-125154.html
Hat der SuperPi Code vielleicht IDIV Befehle dabei ? Oder die "Write Output Buffers" ? Was auch immer das ist ^^
[/Edit]

Noch was zu dem Thema, Sandy hat auch *keinen* Loop Detector:

3.7 Branch prediction in Intel Sandy Bridge
The Sandy Bridge reverses the trend of ever more complicated branch prediction algorithms
by not having a separate predictor for loops. The redesign of the branch prediction
mechanism has probably been necessary in order to handle the new µop cache (see page
95 below). A further reason for the simplification may be a desire to reduce the pipeline
length and thereby the misprediction penalty.

Und Core2 und PentiumM angeblich den gleichen Predictor(mit LoopDet):

3.5 Branch prediction in PM and Core2
The branch prediction mechanism is the same in PM and Core2.

http://www.agner.org/optimize/microarchitecture.pdf

Also irgendwie ist der Schlüssel zu SuperPi wohl wirklich der Unterschied zw. Dothan und Yonah, und der Loop Detector kanns wher nicht sein. Vielleicht haben sie beiM Yonah die reservation stations aufgebohrt, wie kürzlich bei Sandy? Mal googlen... auf alle Fälle ein interessanter Fall.

Nee, Bobcat soll bei ~48 Sekunden (1M) liegen. Woher die hohen Werte kommen? Vielleicht wieder irgendwelche verkrüppelten Samples? Etwas weniger als 50 Sekunden für 1,6 GHz ist jedenfalls ziemlich gut. Das ist vergleichbare Taktperformance zu meinem X2 240. Sicherlich bremst die halbierte FPU bei Bobcat nicht, ist ja eh nur x87. Dennoch, für ein so kompaktes 2-fach OoO Design, mit einem Speicherdurchsatz der knapp über der Grasnarbe liegt, beachtlich. Da hat man intern offenbar ordentlich optimiert. Das lässt für Bulldozer hoffen.

Lol, merke: Nächstes Mal wenigstens nen 2ten Googletreffer auswerten ^^
50s sind ganz ok, stimmt. Da scheint der neue, "genetische" Branch Predictor ganz gut zu sein(bin mit bei dem "genetic" nicht mehr sicher, irgedwas mit "g" war es. Auf alle Fälle soll das Teil für die DIE Größe Spitzenwerte liefern, ein AMD Entwickler wurde irgendwo sehr stolz zitiert. Und/oder der unified INT(16entries) bzw. unified FP Scheduler(18e) ist der "Schuldige" ;-)

Ist zwar 'ne schöne Theorie, halte ich aber nicht für sonderlich wahrscheinlich. In der Vergangenheit hat dieser Test auch schon mal Nullnummern angezeigt, weil er bestimmte Prozessoren noch nicht kannte. Ich sehe momentan eigentlich nur zwei Probleme, Fakes und falsch berechneter Takt (Multi).

Hm ok, aber trotzdem könnte es noch ein Hardwaredefekt sein. Wieso sollte das Programm eigentlich 0 Nummern anzeigen, was messen die da? Mehr als ein paar MOVs oder sonstige Speicheroperationen wirds doch nicht sein, wie kann man da auf 0er Ergebnisse kommen, strange ...

ciao

Alex

P.S:
Hier noch ein 3GHz Yonah SPi Run, passend zum vorherigen Dothan:
http://www.abload.de/img/fileem90.jpg
19sec. also 5 sec. besser als Dothan.

Und dazu passend noch ein Conroe Run@3 Ghz:
http://imageshack.us/photo/my-images/291/superpic2d3ghzvu9.jpg/
17s. nur 2 Sec. mehr, das kann auf Konto der +2MB Cache gehen.

 

[classic437]

Sachmal seid ihr alle Informatik Studenten oder warum habt ihr soviel Ahnung von der Materie ?