Zambezi - Fehler, Bugs, mangelnde Performance - Woran liegt es?

[Ge0rgy]

Also AFAIK war die Branch Prediction bei den K10 noch nicht so das Gelbe vom Ei.
Agner Fog hat mal einen K10 / Core2 - Vergleich gebracht zu Barcelona-Zeiten und dabei hat er die Sprungvorhersage der Core2-Architektur explizit wegen ihrer exzellenten Trefferquote gelobt. Die vom K10 war zwar ok, aber nicht sooo der Wahnsinn. Sogar der K6 soll eine vergleichsweise sehr gute Branch Prediction gehabt haben während die vom K7 wiederum als "eher simpel" bezeichnet wurde.
Da die K8 und K10 vergleichsweise ziemlich große L1 - Caches hatten mag das Ganze abgefedert worden sein. Dennoch war die Branch Prediction nicht unbedingt AMDs große Stärke in den letzten Architekturen. Ergo eine Verbesserung tut hier Not.
Zumal mit längeren Pipelines auch eine Missprediction mehr wehtut.
Trotzdem sei angemerkt, dass BDs Pipeline nicht übertrieben lang ist. Ein paar Stufen mehr als K10, aber immernoch im Rahmen dessen was z.B. Nehalem hatte.
BD hat im Moment das Problem dass der L1 klein ist, das Write-Through Cachedesign auf dem Desktop eher suboptimal und wenn dann dazu noch die Branch-Prediction verbesserungswürdig ist - nunja...
Also sollen sies Verbessern und dann schau mer was rauskommt.

 

[Complicated]

Hmm, und woher hast du, dass diese bis zu 98% auf aktuelle x86 CPUs zutrifft? Ich muss aber zugeben, dass ich jetzt aber nicht alles gelesen habe.

Den Abschnitt habe ich doch zitiert

 

[Ge0rgy]

@Compilcated
Das ist aber eine sehr generelle Aussage die einfach mal "moderne CPUs" über einen Kamm schert, dabei bin ich mir ziemlich sicher dass es da deutliche Unterschiede gibt.
Oftmals werden mit "moderne CPUs" nämlich auch nur die letzten 2 Generationen Intel-Chips beschrieben...

 

[Complicated]

Nun ja der Link auf Anand von Lynxeye bestätigt das ja. Ich wollte das einfach nur mal ins Verhältnis setzen, da ich die kolportierten 30% Verbesserung der "falschvorhersage" schwerlich als beste Performance Verbesserung ausmachen kann.

Auch sieht man bei Anand, dass der K10 nicht besser als BD war und somit auch dort nicht die Ursache für manches schlechtere Benchmark Ergebnis zu suchen ist - Cinbebench war ja gerade so ein Kandidat der oft als "Beweis" herangezogen wurde, dass BD langsamer als K10 sei.

 

[Ge0rgy]

Nun, ein Audi TT RS verliert auch gegen einen Porsche Cayenne... - im Offroad-Track...

 

[aylano]

Wo sich aber natürlich die Frage stellt, wie gut der neue Prozess anläuft und sich entwickelt. Wenn die Fehleranfälligkeit höher ist wie beim doch schon seit einiger Zeit laufenden 32nm Prozess, ist es ja nichteinmal zwangsweise billiger...
Ohne Zahlen zu kennen, ist das alles beschissen zu beurteilen

Klar, neben der unbekannten Performance-Effizienz und Performance (max-Takt) kommt beim 28nm-Bulk neben der Flächenreduzierung die unbekannte Yield hinzu.

Aus irgendwelchen Gründen sollten 28nm-Bulk besser [Performance-Effizienz-Frage oder die Kosten-Frage (Yield*Fläche)]sein als 32nm-SOI, da AMD sonst keinen Anreiz hätte, diesen zu verwenden. Da bei AMD schon die eine oder andere Fertigung etwas in die Hose ging (= Verspätungen & Yield) sind Probleme nicht auszuschließen.

Deshalb achte ich auf Yield-Aussagen von Kaveri & Kabini besonders.
Wobei auch jene "Aussagen" interessant sind, die nicht gemacht wurden.
Denn Trinity wurde erstmals Juni 2011 gezeigt und lauffähig schon Sept 2011.
Wenn es langsam kein Lebenszeichen von Kaveri gibt, dann wäre das weniger gute Anzeichen, für einen guten Start Mitte 2013. Aber nicht jedes Anzeichen muss dann der Tat entsprechen.

 

[amdfanuwe]

Vielleicht hat Rory was an der Informationspolitik geändert? Erst sicherstellen, dass man was ordentliches hat und produzieren kann, dann erst an die Öffentlichkeit?
Llano und BD haben AMDs Ruf ziemlich geschadet weil zu viele Erwartungen geweckt wurden.

 

[Helle53]

Zur Branch Prediction: Getestet eben mit FX-8120, Cinebench R11.5 (64-Bit), Einzelkern, festgepinnt auf Core0, Nutzung der Performance_Event_Counter: Falsche Sprungvorhersage ca. 5,4%: Sprung-Instruktionen ca. 197,9 Mrd., davon falsch vorhergesagt ca.10,7 Mrd. (damit die Größenordnungen klar werden !).

 

[Ge0rgy]

ok, also immerhin eine Trefferquote von knapp 95%.
Damit können wir die tolle +30% Verbeserung erstmal als Marketingzahl betrachten...

 

[Helle53]

@GeOrgy: Bitte beachten: Der Wert bezieht sich auf eine bestimmte Anwendung (hier Cinebench)! Ich habe das "Hintergrund-Rauschen" rausgerechnet (würde aber nichts weiter am Prozent-Wert ändern). Lasse ich auf dem Test-PC nichts weiter laufen, also nur die "Dienst-Programme", beträgt die Fehlerquote knapp 8,4%. Da ist aber ein Haufen Novell-Gelumpe dabei, das will ich AMD nun wirklich nicht anlasten . Da ich jetzt zu Hause bin, werde ich das Testprogramm mal für Intel umschreiben und auf meinem i7-3770K testen.

 

[Stryki]

95% bedeutet jeder zwanzigste Sprung geht daneben, wenn man das auf jeden fünfundzwanzigsten optimieren kann (oder fast) wird klar wie abhängig das ganze vom Code ist.
Hat da einer Zahlen Hinweise wie oft so etwas vorkommt und wann? ich hab dunkel in Erinnerung das in der CT selbst kleine Verbesserungen da immer sehr gelobt wurden.

 

[Helle53]

Habe mit dem i7-3770K lange getestet, aber es bleibt dabei (Test-Bedingungen s.o.): Falsche Sprungvorhersage (Cinebench): 1.45%. Idle: 3.99% (mein PC!).

 

[Zarniwoop]

Man darf sich nicht davon täuschen lassen, dass bei einer momentanen (angenommenen) Trefferquote von 95% eine Reduktion der falsch vorhergesagten Sprünge um 30% lediglich eine nicht besonders spetakulär aussehende Steigerung um 1.5%-Punkte auf 96.5% bewirkt.

Wie schon öfters erwähnt, kostet ein falsch vorhergesagter Sprung ein Vielfaches eines richtig vorhergesagten Sprung, und deswegen sind es die fünf Prozent, die Zeit verbrauchen. Und wenn man die um 30% reduzieren kann, dann hat sich eines der wesentlichen Dinge, die Zeit verbrauchen, um 30% verringert.

Meiner Meinung nach ist das also schon ein relativ großes Ding.

Das Gleiche gilt ja auch für Cache-Misses, die ja auch meistens irgendwo im einstelligen Prozentbereich liegen, dafür aber richtig kosten. Auch hier ist jeder gesparte Cache-Miss eine große Verbesserung.

 

[gruffi]

Zur Branch Prediction: Getestet eben mit FX-8120, Cinebench R11.5 (64-Bit), Einzelkern, festgepinnt auf Core0, Nutzung der Performance_Event_Counter: Falsche Sprungvorhersage ca. 5,4%: Sprung-Instruktionen ca. 197,9 Mrd., davon falsch vorhergesagt ca.10,7 Mrd. (damit die Größenordnungen klar werden !).

Soweit ich weiss, ist der Fritz Chess Benchmark sehr abhängig von guter Sprungvorhersage. Könntest du das mal testen? Den Benchmark findest du zB hier.

 

[Complicated]

Ich denke hier wäre tatsächlich auch noch mal interessant zu wissen wie gross die "Penalty" ist bei Falschvorhersagen. Ist diese im Prinzip so lang wie die Pipline in Takten?
Würde das heissen je kürzer die Pipeline, desto geringer die "Penalty" bei Missprediction?

Das würde im Prinzip bedeuten, dass bei 95% Trefferquote und einer 20 stages langen Pipe (rein rechnerisch) die 5% falsch vorhergesagten ca. genau so viel Zeit verbrauchen wie die 95% korrekt voraus geladenen Code? Kann man das so ungefähr simple zusammenfassen?

 

[Zarniwoop]

Kann man das so ungefähr simple zusammenfassen?

Well, it's complicated...

Nee mal im Ernst: Das hängt auf jeden Fall zusammen. Es gibt sicherlich einige Optimierungen, dass die Pipeline frühestmöglich geflusht wird wenn klar ist, dass der jump woanders hingeht. Oder dank OoO könnte man bedingte Sprünge möglchst früh auswerten,

 

[Opteron]

Ich denke hier wäre tatsächlich auch noch mal interessant zu wissen wie gross die "Penalty" ist bei Falschvorhersagen. Ist diese im Prinzip so lang wie die Pipline in Takten?
Würde das heissen je kürzer die Pipeline, desto geringer die "Penalty" bei Missprediction?

Jo, einzige Ausnahme ist Intel mit dem neuen (sei Sandy) µOp Cache, der hält auch die Instruktionen für den anderen Zweig vor, d.h. im Falschvorhersagefall spart sich ein Sandy die ersten 3 Pipelinestufen im Decoder.
AMDs Cache in den Patenten war eigentlich genau auch aus diesem Grund geplant, deswegen hieß er ja auch "Redirect / Recovery-Cache".

Keine Ahnung aber, ob AMD den nun einbaut, oder erst nur nen Loop-Detector

 

[gruffi]

Ich denke hier wäre tatsächlich auch noch mal interessant zu wissen wie gross die "Penalty" ist bei Falschvorhersagen. Ist diese im Prinzip so lang wie die Pipline in Takten?
Würde das heissen je kürzer die Pipeline, desto geringer die "Penalty" bei Missprediction?

Im Grunde, ja. Die Penalty für Misprediction sollte bei Bulldozer also mindestens 15 Takte betragen. Pauschalisieren lässt sich das aber nicht. Da spielen noch ein paar andere Faktoren mit rein. Ich würde Agner Fogs Architektur PDF empfehlen. Da steht einiges zu dem Thema und zu verschiedenen x86 Architekturen.

 

[Helle53]

@gruffi: Tut mir leid, aber den Fritz-Test auf dem FX-8120 kann ich erst am Montag durchführen (die Kiste steht im Büro). Ich habe aber eben auf dem i7-3770K getestet: Falsche Vorhersagen = 6,9% (50,1 Mrd. zu 3,47 Mrd., 1 Kern = Core0).

 

[Ramius]

Bei BD liegt die minimale Branch misprediction penalty bei 20 Takten, die maximale Branch misprediction penalty liegt bei < 30 Takten.

Zum Vergleich: Beim K10 liegt die minimale Branch misprediction penalty bei 12 Takten.

Bei SandyBridge liegt die minimale Branch misprediction penalty bei 14 Takten. Nur wenn die Instruktion nicht im µop-Cache gefunden wird, erhöht sich diese auf 17 Takte.

 

[gruffi]

@gruffi: Tut mir leid, aber den Fritz-Test auf dem FX-8120 kann ich erst am Montag durchführen (die Kiste steht im Büro). Ich habe aber eben auf dem i7-3770K getestet: Falsche Vorhersagen = 6,9% (50,1 Mrd. zu 3,47 Mrd., 1 Kern = Core0).

Sind die 50,1 Mrd die gesamten Predictions oder nur die erfolgreichen? Bei letzterem wären es ~6,5%.

Bei BD liegt die minimale Branch misprediction penalty bei 20 Takten, die maximale Branch misprediction penalty liegt bei < 30 Takten.

Der SOG für Family 15h sagt klar was anderes:

The minimum branch misprediction
penalty is 20 cycles in the case of conditional and indirect branches and 15 cycles for unconditional
direct branches and returns.

Zum Vergleich: Beim K10 liegt die minimale Branch misprediction penalty bei 12 Takten.

Auch hier sagt der SOG für Family 10h und 12h klar was anderes:

In the event of a misprediction, the minimum penalty is 10
cycles.

 

[Helle53]

@gruffi: Sind alle abgearbeiteten Sprung-Instruktionen (egal ob Sprung ausgeführt oder nicht). Ich verweise mal auf: "Intel® 64 and IA-32 Architectures Software Developer’s Manual, Combined Volumes: 1, 2A, 2B, 2C, 3A, 3B and 3C; 325462-043US May 2012"; dort Vol.3B, Seite 18-56. Beim Test verwendet habe ich jeweils UMask = 04H (All_branches).

 

[Kunibert_KA]

Laut Anantech:

Branch Prediction
Architecture 					Branch Misprediction Penalty (min)
AMD K10 (Barcelona, Magny-Cours) 	12 cycles
AMD Bulldozer 					20 cycles
Pentium 4 (NetBurst) 				20 cycles
Core 2 (Conroe, Penryn) 			15 cycles
Nehalem 					        17 cycles
Sandy Bridge 					14-17 cycles

Das sind die min Takte. Je nach dem was geladen werden muss usw. kann es auch viel länger werden. Habe da etwas von bis zu 100 cycles beim PIV in Erinnerung.

Die Branch Prediction des Bulldozer ist besser als die des K10, aber schlechter als die des Sandys. Selbst wenn eine Misprediction weniger häufig vorkommt (als beim K10) tut sie mehr weh. Ich glaube nicht das sie so viel besser ist als das sie die härtere Penalty ausgleichen könnte.

Anandtech:
'The numbers above show the minimum branch misprediction penalty, and the fact is that the Bulldozer architecture has a branch misprediction penalty that is 66% higher than the previous generation. That means that the branch prediction of Bulldozer must correctly predict 40% of the pesky branches that were mispredicted by the K10 to compensate (at the same clock). Unfortunately, that kind of massive branch prediction improvement is almost impossible to achieve.'

 

[gruffi]

@Helle53

Ok. Ja dann sind's 6,9%. Kein grosses Ding, war mir nur nicht ganz sicher.

Laut Anantech: ...

Interessiert mir ehrlich gesagt nicht die Bohne, was Anandtech schreibt. Die haben schon zu viel Unsinn zu Bulldozer geschrieben. Die offiziellen Dokumente von AMD sagen jedenfalls eindeutig: Minimum Penalty Stars/Husky = 10 Takte, Minimum Penalty Bulldozer = 15 Takte.