Kürzlich tauchten bei Passmark Benchmarkergebnisse einer Trinity A10-APU mit 2,3 GHz Basistakt und 3,2 GHz Turbotakt auf. Die meisten Messwerte liegen im Bereich des Erwarteten, allerdings zeigten zwei Integer-Teilbenches des CPU-Tests deutliche Anomalien. Dort zieht die kleine Trinity-APU deutlich um das Vier- bis Fünffache gegenüber einem schnellere getakteten FX-4100 davon. Sogar ein i5-2500K wird dabei geschlagen.
Die Erklärung ist zwar eher gewöhnlich, lässt aber auch einen interessanten Schluss zu. Dazu später mehr, konzentrieren wir uns zuerst auf den Benchmark. Im Gegensatz zu normalen Wald-und-Wiesen-Programmcode bestehen die beiden erwähnten Benchmarks zu 25 % aus Divisionsbefehlen. Diese werden von CPU-Herstellern traditionell eher stiefmütterlich behandelt, da sie in normalem Programmcode in weniger als ~1 % der Fälle eingesetzt werden. Trotzdem nehmen sich die CPU-Architekten seit ein paar Jahren doch dieses Themas an: Intel führte eine Divisionseinheit in Hardware mit der Penryn-Generation ein. Siehe dazu auch unsere Meldung zur Divisionseinheit der 3. Bulldozer-Generation Steamroller: Steamroller (Bulldozer_v3) bekommt eine Radix-8-Dividierer-Einheit.
Nun gibt es aber einen Unterschied zwischen AMD und Intel, der bei beiden Firmen seit seligen K7- bzw. Pentium-Pro-Zeiten besteht. Intel verarbeitet in den Rechenwerken meist Ganz- und Gleitkommazahlen zusammen, bei AMD wird dies strikt getrennt. Vorteil für Intel: Man spart Die-Fläche ein, da keine doppelt angelegten Rechenwerke benötigen werden. Vorteil für AMD: Dort werden die Rechenwerke auf den jeweiligen Einsatz besser spezialisiert und optimiert, siehe AMDs FlexFPU-Konzept. Aber der Nachteil ist eben, dass man noch eine zusätzliche Dividier-Einheit für Integer benötigt. Lange hatte man bei AMD nichts, aber schließlich bekamen die K10-Kerne der Llano-APU eine kleine Überarbeitung, zu der auch eine Integer-Divisions-Einheit gehört. Wir erwähnten diese zum Llano-Start nur kurz in unserem Artikel: Llano-APU – "The Big Iron".
Bulldozer baute natürlich darauf auf und ist ebenfalls mit einer Integer-Divisionseinheit ausgerüstet, wie man hier in der Detailansicht erkennen kann:
Quelle: AMD ISSCC 2011 Papers, nicht frei verfügbar
Leider gab es nun beim Llano aber einen Bug, weshalb AMD empfiehlt, die Einheit abzuschalten:
Zitat:
665 Integer Divide Instruction May Cause Unpredictable Behavior
Description Under a highly specific and detailed set of internal timing conditions, the processor core may abort a speculative DIV or IDIV integer divide instruction (due to the speculative execution being redirected, for example due to a mispredicted branch) but may hang or prematurely complete the first instruction of the non-speculative path.
Potential Effect on System Unpredictable system behavior, usually resulting in a system hang.
Suggested Workaround BIOS should set MSRC001_1029[31]. This workaround alters the DIV/IDIV instruction latency specified in the Software Optimization Guide for AMD Family 10h and 12h Processors, order# 40546. With this workaround applied, the DIV/IDIV latency for AMD Family 12h Processors are similar to the DIV/IDIV latency for AMD Family 10h Processors.
Fix Planned No
Nach und nach dürfte AMDs Empfehlung in BIOS-Updates integriert werden. Die Folge sind starke Einbrüche bei den beiden angesprochenen Passmark-Tests, symptomatisch hier der Integer-Test:
Wie man sieht ein "kleiner" Unterschied um den Faktor 5. Das Leistungsniveau mit Patch entspricht recht genau dem eines normalen K10-Chips mit gleichem Takt, in unserem Beispiel ein 960T unseres Forenmitglieds "LehmannSaW". Dieser Sachverhalt wurde auch im Passmark-Forum diskutiert, die Programmierer dort brachten einen Patch heraus, der die Divisionseinheit trotzdem aktivieren kann: Passmark-Forum
Die Preisfrage ist aber nun: Was kann die starken Trinitys-Zuwachsraten erklären? Schließlich handelt es sich um einen Llano-Bug, von dem die Bulldozer-Einheit nicht betroffen ist. Zumindest gibt es keinen entsprechenden Eintrag im Bulldozer-Errata-PDF. Die Unterschiede zwischen dem Trinity-A10-Sample und einem FX4100 mit deutlich mehr Takt sind aber trotzdem ähnlich deutlich wie bei der K10-Generation:
Konsequenterweise kann die Integer-DIV-Einheit bei den aktuellen Bulldozer deshalb auch nicht aktiviert sein. Falls AMD den Dividierer von Haus aus - also vom Marktstart an - deaktiviert hat, dann gibt es auch keinen Grund einen Bug in Bulldozers Errata-Liste aufzuführen. Ein indirekter Hinweis findet sich nur in den diversen Optimierungs-Leitfäden für die CPU-Familien 10h&12h (K10- und Llano-Chips) und 15h (Bulldozer). Im K10-Leitfaden heißt es bei den Integer-Divisionsbefehlen des Llanos:
Zitat:
For AMD Family 12h it is recommended to use the division instructions DIV or IDIV (refer to Appendix C to review the latency of DIV/ IDIV instructions). DIV and IDIV instructions are now fastpath instructions.
"Fast-Path" bedeutet, dass die Dekoder-Einheit, die x86-Befehle in interne MacroOps übersetzt, den entsprechenden x86-Befehle quasi auf der "Überholspur" 1:1 durch einen einzigen der drei (K10) bzw. vier (Bulldozer) vorhandenen Dekoder dekodieren kann. Die restlichen Dekoder können parallel andere x86-Befehle abarbeiten. Der Gegensatz dazu heißt je nach Nomenklatur "Microcode" bzw. "Vector-Path". Dabei generiert einer der 3 bzw. 4 Dekoder eine lange Befehlskette, die restlichen stehen still. Je nach Befehl kann das schlimmstenfalls 30++ Takte dauern, während dessen keine anderen Befehle übersetzt werden können. Im Bulldozer-Fall ist das noch etwas schlimmer, da sich das natürlich auf beide Kerne eines Moduls bezieht. Sobald nur ein Thread von einem Vector-Path-Befehl aufgehalten wird, können für beide Threads keine neuen Befehle mehr eingelesen werden. Die gute Nachricht dabei ist, dass so gut wie alle Befehle ( >90%) vom Typ Fast-Path sind. Divisionsbefehle gehören aber eben (noch) nicht dazu und kosten ein bisschen Leistung. Nun aber zurück zu Bulldozer und seiner DIV-Einheit:
Schlägt man im Family-15h-Optimierungs-Handbuch nach, so findet man folgende Einträge:
Zitat:
DIV reg microcode microcode DIV mem microcode microcode
Es kommt also - obwohl es eigentlich eine Hardware-Einheit dafür gibt - nur wieder die umständliche Microcode-Lösung zum Einsatz. Somit ist klar, dass die Integer-Divisions-Logik bei den aktuellen Bulldozer-CPUs ebenfalls deaktiviert sein muss. Wieso das nicht explizit erwähnt wird ist allein AMDs Geheimnis.
Offene Frage ist jetzt nur noch, ob man eventuell mit Setzen des gleichen Bits wie beim Llano-Fix auch bei Bulldozer die Divisions-Einheit (re)aktivieren könnte (und sich damit auch ein instabiles System einhandelt). Mutigen Zeitgenossen sei unsere alte Anleitung zum Umgehen des TLB-Bug-Fixes des 65nm-Phenoms empfohlen:
Einfach die obigen, im Errata 665 angegebenen Daten rückgängig machen (also Bit 31 auf 0 setzen) und den Effekt (so der PC nicht abstürzt) mit Passmarks CPU-Test überprüfen und im Erfolgsfall zu Passmark hoch laden. Als Upload-Name böte es sich aus Suchgründen an, seinen Wunschnamen mit einem "P3D_IDIV" Präfix zu versehen. Hinweis: Für Schäden oder Datenverlust übernehmen wir natürlich keine Garantie, jeder testet auf eigene Gefahr.
Danke an LehmanSaW fürs ursprüngliche Finden der A10-Benchmarks.
Diesen Artikel bookmarken oder senden an ...