News Trinity mit aktivierter Integer-Divisions-Einheit: Auch auf FX-Chips reaktivierbar?
- Ersteller Opteron
- Erstellt am
-
- Schlagworte
- amd-fx piledriver trinity
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
<div class="newsfloatleft"><a href=""><img src="http://www.planet3dnow.de/photoplog/images/54308/1_AMD-Logo.png" border="0" alt="AMD-Logo"></a></div>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: <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1330556976">Steamroller (Bulldozer_v3) bekommt eine Radix-8-Dividierer-Einheit</a>.
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 <a href="http://blogs.amd.com/work/2010/10/25/the-new-flex-fp/" target="b">FlexFPU-Konzept</a>. 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: <a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=395605&garpg=3#content_start">Llano-APU – "The Big Iron"</a>.
Bulldozer baute natürlich darauf auf und ist ebenfalls mit einer Integer-Divisionseinheit ausgerüstet, wie man hier in der Detailansicht erkennen kann:
<center><img src="http://www.planet3dnow.de/photoplog/file.php?n=19808&w=o">
<FONT SIZE=-2>Quelle: AMD ISSCC 2011 Papers, nicht frei verfügbar</FONT></div></center>
Leider gab es nun beim Llano aber einen Bug, weshalb AMD empfiehlt, die Einheit abzuschalten:
<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat:</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i><B>665 Integer Divide Instruction May Cause Unpredictable Behavior</B>
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.
<b>Fix Planned</b>
No</i></td></tr></tbody></table></div>
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:
<center><img src="http://www.planet3dnow.de/photoplog/file.php?n=19807&w=o"></center>
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:
http://www.passmark.com/forum/showthread.php?t=3656
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:
<center><img src="http://www.planet3dnow.de/photoplog/file.php?n=19806&w=o"></center>
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:
<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat:</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i>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 <b>fastpath instructions</b>.</i></td></tr></tbody></table><FONT SIZE=-2>Quelle: <a href="http://support.amd.com/us/Processor_TechDocs/40546.pdf" target="b">AMD PDF</a> </FONT></div>
"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:
<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat:</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i>DIV reg microcode microcode
DIV mem microcode microcode</i></td></tr></tbody></table><FONT SIZE=-2>Quelle: <a href="http://support.amd.com/us/Processor_TechDocs/47414_15h_sw_opt_guide.pdf" target="b">AMD PDF</a></FONT></div>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:
<a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=330868&garpg=4">AMD Phenom ohne TLB-Fix - so geht´s</a>
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.
<b>Links zum Thema:</b><ul><li><a href="http://blogs.amd.com/work/2010/10/25/the-new-flex-fp/" target="b">The New Flex FP (Englisch)</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1330556976">Steamroller (Bulldozer_v3) bekommt eine Radix-8-Dividierer-Einheit</a></li><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=395605&garpg=3#content_start">Llano-APU – "The Big Iron"</a></li><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=404165">Diskussion um Forum</a></li></ul>
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: <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1330556976">Steamroller (Bulldozer_v3) bekommt eine Radix-8-Dividierer-Einheit</a>.
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 <a href="http://blogs.amd.com/work/2010/10/25/the-new-flex-fp/" target="b">FlexFPU-Konzept</a>. 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: <a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=395605&garpg=3#content_start">Llano-APU – "The Big Iron"</a>.
Bulldozer baute natürlich darauf auf und ist ebenfalls mit einer Integer-Divisionseinheit ausgerüstet, wie man hier in der Detailansicht erkennen kann:
<center><img src="http://www.planet3dnow.de/photoplog/file.php?n=19808&w=o">
<FONT SIZE=-2>Quelle: AMD ISSCC 2011 Papers, nicht frei verfügbar</FONT></div></center>
Leider gab es nun beim Llano aber einen Bug, weshalb AMD empfiehlt, die Einheit abzuschalten:
<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat:</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i><B>665 Integer Divide Instruction May Cause Unpredictable Behavior</B>
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.
<b>Fix Planned</b>
No</i></td></tr></tbody></table></div>
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:
<center><img src="http://www.planet3dnow.de/photoplog/file.php?n=19807&w=o"></center>
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:
http://www.passmark.com/forum/showthread.php?t=3656
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:
<center><img src="http://www.planet3dnow.de/photoplog/file.php?n=19806&w=o"></center>
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:
<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat:</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i>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 <b>fastpath instructions</b>.</i></td></tr></tbody></table><FONT SIZE=-2>Quelle: <a href="http://support.amd.com/us/Processor_TechDocs/40546.pdf" target="b">AMD PDF</a> </FONT></div>
"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:
<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat:</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i>DIV reg microcode microcode
DIV mem microcode microcode</i></td></tr></tbody></table><FONT SIZE=-2>Quelle: <a href="http://support.amd.com/us/Processor_TechDocs/47414_15h_sw_opt_guide.pdf" target="b">AMD PDF</a></FONT></div>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:
<a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=330868&garpg=4">AMD Phenom ohne TLB-Fix - so geht´s</a>
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.
<b>Links zum Thema:</b><ul><li><a href="http://blogs.amd.com/work/2010/10/25/the-new-flex-fp/" target="b">The New Flex FP (Englisch)</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1330556976">Steamroller (Bulldozer_v3) bekommt eine Radix-8-Dividierer-Einheit</a></li><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=395605&garpg=3#content_start">Llano-APU – "The Big Iron"</a></li><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=404165">Diskussion um Forum</a></li></ul>
Top Bericht! Werde nachher mal testen, ob ich die Deaktivierung umgehen kann.
Gruß
EDIT:
Du schreibst man sollte die Daten aus dem Errata-Eintrag eingeben, also:
Aber würde die nicht genau das Gegenteil bewirken; sprich den Divisionseinheit deaktivieren?
Zuletzt bearbeitet:
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Ja klar, aber das sollte man in RW-Everything sowieso sehen. Das Bit muss ja schon gesetzt sein. Das dann eben auf 0 umändern. Ich hab die Textpassage mal etwas umformuliert.
Crashtest
Redaktion
☆☆☆☆☆☆
Im Bulldozer Ver. "0.9x" (OR-Bx) sollte einiges noch "deaktiviert" sein:
- FMA3,
- CVT16/F16C
- Div-Unit
- BMI1
- Teile von BMI2
- Teile des kommenden AVX2
Einiges lässt sich per µCode aktivieren, einiges per MSR
Allerdings sind manche Sachen aus gutem Grund "deaktiviert" - weil es zu dem Zeitpunkt halt noch nicht richtig fertig war (zB FMA3 im OR-B2).
AMD muss ja auch noch einiges aus dem Hut zaubern können ...
- FMA3,
- CVT16/F16C
- Div-Unit
- BMI1
- Teile von BMI2
- Teile des kommenden AVX2
Einiges lässt sich per µCode aktivieren, einiges per MSR
Allerdings sind manche Sachen aus gutem Grund "deaktiviert" - weil es zu dem Zeitpunkt halt noch nicht richtig fertig war (zB FMA3 im OR-B2).
AMD muss ja auch noch einiges aus dem Hut zaubern können ...
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Na für die ganzen Befehlssatzerweiterungen ist das ja ok, die wurden auch nicht versprochen bzw. offiziell beworben. Die Hardware-iDiv-Einheit dagegen stand in den offiziellen Papers. Vermutlich dann auch der Grund, wieso man das nicht kommuniziert hat. Wär wohl schon peinlich, wenn man zugeben müßte, dass es in der neuen CPU noch diesen und jenen Fehler gibt, weswegen Einheiten abgeschaltet worden sind.
Makso
Grand Admiral Special
So hab jetzt auch mal meinen 1090T das erste mal gepasstmarkt?
http://www.planet3dnow.de/vbulletin/attachment.php?attachmentid=25259&stc=1&d=1334579250
Was wirkt das aus an der Performance eines Llano od. Bulli?
http://www.planet3dnow.de/vbulletin/attachment.php?attachmentid=25259&stc=1&d=1334579250
Was wirkt das aus an der Performance eines Llano od. Bulli?
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Kommt ganz drauf an, wieviel Divisionen Du im Code hast. Normalerweise nicht viel, wie im Text beschrieben so ~1%. Aber bei Spielen würde mich mal die Bethseda-Abteilung interessieren, deren Spiele sind grottig optimiert. Immerhin war der Druck so groß, dass es am Ende nen Skyrim Patch gab.
Makso
Grand Admiral Special
Versteh. Eigentlich ist die Einheit fürn Hugo momentan. oder?
gruffi
Grand Admiral Special
Kleine textliche Anmerkung. In "weniger als ~1 %" ist das "~" überflüssig. "Weniger als 1%" reicht völlig aus.
Ansonsten, interessantes Thema. Mich wundert nur, dass die DIV Einheit so viel Auswirkung auf den Bench hat. Die Frage wäre, ob dort so viel Division vorkommt oder ob die DIV Latenzen solche Auswirkungen auf den gesamten Integer Cluster von AMD hat.
Ansonsten, interessantes Thema. Mich wundert nur, dass die DIV Einheit so viel Auswirkung auf den Bench hat. Die Frage wäre, ob dort so viel Division vorkommt oder ob die DIV Latenzen solche Auswirkungen auf den gesamten Integer Cluster von AMD hat.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Jo nicht so das zwingende Thema, läuft ehe runter "Kleinvieh macht auch Mist".
Steht im Text:
Das haut dann natürlich rein. Auf meinem K10 hab ich die IPC mit PerMon gemessen, die lag bei sagenhaften 0,3-0,4.
gruffi
Grand Admiral Special
Das ist für mich trotzdem keine ausreichende Erklärung. Ich sehe mit Patch eine ~5,7 mal so hohe Performance. Wenn diese nur durch Divisionen zustande kommt, welche 25% des Benches ausmachen, müsste das eine ~22,8 mal so leistungsfähige DIV Einheit bedeuten. Klingt nicht sonderlich plausibel, wenn du mich fragst. Sicherlich ist der Hardware Divider leistungsfähiger. Aber um so viel?
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Hab oben noch die IPC ergänzt. Sicherlich wird die durch die Microcode-DIVs "gut" runtergebremst.
Ansonsten gibts noch die Tabelle hier:
Schlimmstenfalls (bei IDIV, 64bit) also ein größter, anzunehmender Unterschied vom Faktor 79/9 = ~9. Im Mittel wirds aber sicherlich deutlich weniger sein.
@Sightus:
Wohl eher nicht, Divisionen vermeidet man so oft es geht. Glaub jetzt nicht, dass es da sooo unfähige Boinc-Programmierer gibt ^^
WindHund
Grand Admiral Special
Das klingt ja viel versprechend, mal sehen ob es auch funktioniert.
Bis jetzt konnte ich noch keine Auswirkungen fest stellen, dafür bräuchte ich noch ein wenig hilfe bei RW_everything.
Hier mal mein FX ohne den Patch: (V7, build:1028 )
Ganz knapp hinter dem I7-2700K, da muss doch mehr möglich sein!
Bis jetzt konnte ich noch keine Auswirkungen fest stellen, dafür bräuchte ich noch ein wenig hilfe bei RW_everything.
Hier mal mein FX ohne den Patch: (V7, build:1028 )
Ganz knapp hinter dem I7-2700K, da muss doch mehr möglich sein!
WindHund
Grand Admiral Special
@Nero24
Das ist ja das Problem, so schaut es bei mir aus: http://h11.abload.de/img/rw-everythingpkkt5.jpg
Es sieht so aus, als wären nur 4 von 8 IDIV aktiv, leider lässt sich Bit 31 nicht ändern, allerdings kann ich z.B. Bit 10 ändern, das wird dann auch übernommen.
Die Bit mit gelben Hintergrund lassen sich scheinbar ändern, die grauen sind "schreibgeschützt"
Das ist ja das Problem, so schaut es bei mir aus: http://h11.abload.de/img/rw-everythingpkkt5.jpg
Es sieht so aus, als wären nur 4 von 8 IDIV aktiv, leider lässt sich Bit 31 nicht ändern, allerdings kann ich z.B. Bit 10 ändern, das wird dann auch übernommen.
Die Bit mit gelben Hintergrund lassen sich scheinbar ändern, die grauen sind "schreibgeschützt"
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Entweder das, oder es ist ein anderes Bit als beim Llano. Wer weiß schon, was AMD da treibt.Also bei meinem FX-6100 steht Bit 31 von Haus aus auf 0 und ein Ändern auf 1 bewirkt keinen Unterschied.Möglicherweise ist die Einheit "in Hardware" deaktiviert?
Hmmm und irgendeinen Effekt bei Bit10?
Schau mal spasseshalber in CPU-Z oder HWInfo u.ä. ob Du plötzlich FMA3 oder so hast
Dresdenboy
Redaktion
☆☆☆☆☆☆
Das ist wohl ein hübscher Nebeneffekt der DIV-Latenzen. Wenn der Entwickler zwar von 25% Anteil spricht und wahrscheinlich die Anzahl ausgeführter Befehle meint, haben die Divisionen an der Laufzeit dennoch einen hohen Anteil. Bei beispielsweise ~40 Zyklen Latenz und angenommenen ~2 Zyklen für die restlichen Befehle ergäbe das etwa ~(0,25*40+0,75*2)=11,5 Zyklen durchschnittliche Latenz. Ohne Division wären es 2, also erhöhen die nur 25% Divisionen die Gesamtlatenz im Beispiel um den Faktor 6. Dann könnte man die anderen Befehle auch weglassen.
Super Artikel!
Übrigens haben die englischsprachigen Leser dank Google etwas Lustiges beobachtet:
http://semiaccurate.com/forums/showpost.php?p=159629&postcount=3
Ich habe mal im Original-HTML reingeschaut. Da kommt durch irgendeine Link/Bild-Info das "Intel PDF" rein
Sieht natürlich lustig aus, wenn es "übersetzt" worden scheint.Übrigens fiel mir heute beim Ebook-Lesen noch auf, dass in den Instruction Tables von Agner Fog beim BD auch jede Menge Ops (=Microcode) und Latenzen ähnlich der 10h-Latenzen gemessen hat:
http://agner.org/optimize/instruction_tables.pdf
WindHund
Grand Admiral Special
Es muss wohl ein anderes Bit sein.Hmmm und irgendeinen Effekt bei Bit10?
Schau mal spasseshalber in CPU-Z oder HWInfo u.ä. ob Du plötzlich FMA3 oder so hast
Beim ausprobieren ist mir aufgefallen, dass sich auch die grauen Werte ändern lassen, aber nur bis Bit 29.
Hab aber bisher noch nicht alle probiert, das wird mir heute auch zuviel!
Hab mal spaßhalber "DIV=0xC0011029" hinzugefügt, damit bricht die Floating Point Math auf ~2100pkt zusammen beim Performance Test V7 (64Bit).
Auch wenn ich das MSR Register wieder lösche, erst nach einem Neustart erhalte ich die 5900pkt wieder.
deadohiosky
Gesperrt
- Mitglied seit
- 13.07.2011
- Beiträge
- 1.624
- Renomée
- 26
Das mit dem Übersetzen sind meines Erachtens ein paar Intel-Trolle die bei Google eine "bessere Übersetzung" vorschlagen. Das ist schon seit Ewigkeiten so. Einfach mal einen Artikel ins Englische übersetzen lassen und es ist relativ wahrscheinlich, dass AMD als Intel übersetzt wird.
Ansonsten kann ich mich nur Anschließen sehr guter Artikel, Opteron. Ich hoffe der Dank der Community reicht dir aus.
Ich frage mich nur... ist der Hardware-Decoder bei Llano/bulldozer defacto ausgeschaltet oder ist es eher eine Vermutung. Denn auf den Passmark als Indiz würde ich mich da nicht allein verlassen wollen, da könnte ja auch andere Dinge verquer liegen, als besonders kompetent kommen mir die Leute da nicht rüber. Für mich kommen die eher wie Milchbauern vor die dumme und junge Kühe bis zum Letzten melken wollen, mit alten, rostigen Anlagen, deren Druckanzeigen nicht richtig funktionieren und völlig falsche Werte ausgeben.
Ansonsten kann ich mich nur Anschließen sehr guter Artikel, Opteron. Ich hoffe der Dank der Community reicht dir aus.
Ich frage mich nur... ist der Hardware-Decoder bei Llano/bulldozer defacto ausgeschaltet oder ist es eher eine Vermutung. Denn auf den Passmark als Indiz würde ich mich da nicht allein verlassen wollen, da könnte ja auch andere Dinge verquer liegen, als besonders kompetent kommen mir die Leute da nicht rüber. Für mich kommen die eher wie Milchbauern vor die dumme und junge Kühe bis zum Letzten melken wollen, mit alten, rostigen Anlagen, deren Druckanzeigen nicht richtig funktionieren und völlig falsche Werte ausgeben.
Herr Melin
Captain Special
- Mitglied seit
- 18.06.2011
- Beiträge
- 223
- Renomée
- 14
Auch der Napierian Test im Crystalmark spuckt exorbitant höhere Ergebnisse bei Llano vs. Phenom aus und das bei 2,9 GHz vs. 3,4 GHz. Gewöhnlich liegen die Ergebnisse wg. gleicher Architektur und geringerem Takt knapp 20 % hinten, doch plötzlich räufelt Llano bei Napierian und 17 % Taktnachteil den Phenom um 50 % ab:
http://club.coneco.net/user/41992/review/88142/
CPU AMD Phenom II X4 965 3.4GHz
[ ALU ] 53215
Fibonacci : 19779
Napierian : 9006
Eratosthenes : 7973
QuickSort : 16435
http://cheap-wides.net/weblog/img/ph/110810_crystalmark_mtest.html
oder
http://www.tomshardware.co.uk/forum/296163-12-latest-llano-structure-gigabyte-a75m-review
CPU AMD A8-3850 2,9 GHz
Fibonacci : 16932
Napierian : 13469
Eratosthenes : 6517
QuickSort : 14378
Inwiefern dort die Divisionseinheit die Finger im Spiel hat, keine Ahnung.
Zuletzt bearbeitet:
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.066
- Renomée
- 10.446
Dazu müsste ja eigentlich der K15 BIOS Configurationguide Auskunft geben. Mal sehen, ob dort was zu finden ist...
Nachtrag: laut BIOS and Kernel Developers Guide für den Bulldozer ist das Register C0011029h genau wie beim K12 für den Decoder zuständig. Allerdings sind die Bit 63-11 laut Guide "reserved". Ob sie funktionslos sind, geht daraus nicht hervor. Da sie aber offenbar auch nicht änderbar sind im laufenden Betrieb, ist es eh egal.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Naja, beim Llano gehts ja anscheinend im laufenden Betrieb, siehe die Passmark-Patch.
Eventuell gehts nur nicht mehr mit RW-Everything, Vielleicht fängt Windows7 mittlerweile solche Systemänderungen ab?
Was ich dann aber in jedem Fall nicht kapier ist, wieso es bei deinem FX6100 schon auf 0 steht. Das dürfte dann eigentlich nicht sein ...
Außer "0" steht jeweils für den Auslieferungszustand, wär aber dann recht merkwürdig.
@WindHund:
Lol, hast Du da die FPU abgeschalten, oder wie?
Viel Spass beim Testen, und ja - nur keinen Stress
- Mitglied seit
- 01.07.2000
- Beiträge
- 24.066
- Renomée
- 10.446
Das bezweifelt niemand
Ich habs mit Crystal CPUID x64 versucht. Hatte nur beim ersten Versuch (siehe oben) versäumt, das Register zu reloaden; dann hätte ich gleich gesehen, dass der Wert nicht übernommen wurde.
Naja, die Bits 63-11 sind reserved. Und reserved Bits sind idR genullt.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Aso, dachte Du zweifelts daran, da Du meintest, dass sie nicht änderbar seien.Das bezweifelt niemand
Zumindest für nen Llano mit Patch sollte die Regel nicht gelten. Mal schauen, ob Fusion-Besitzer was sagen könnenNaja, die Bits 63-11 sind reserved. Und reserved Bits sind idR genullt.
Ähnliche Themen
