AW: AMDs Zen: Neue Architekturdetails sprechen für deutlich höhere Integer-Leistung
Artikel schrieb:
Ab Haswell unterstützt Intel überdies FMA3, womit eine weitere Verdoppelung des Durchsatzes erreicht werden konnte.
Kann Piledriver auch (sogar das an sich sinnvollere FMA4, was Intel aber nicht hinbekommen hat und stattdessen mit dreimal so vielen verschiedenen Befehlen arbeitet).
Falls das mit dem neuen FPU-Layout stimmen sollte, wird Zen FMA möglicherweise nur noch über zwei µOps mit entsprechendem Rounding-Modus emulieren, was den maximal möglichen Durchsatz natürlich halbieren würde. Was schade wäre, denn vollwertige FMA-Pipelines, die eben sowohl multiplizieren als auch addieren können, sind flexibler und eben durchsatzstärker als solche, die nur eins von beidem beherrschen.
4x128 Bit-FMA wären allerdings tatsächlich besser als die 2x256 Bit-FMA von Intel, weil a) kaum einer AVX nutzt und b) der Schritt von 128 Bit auf 256 Bit auch nicht immer einfach ist, wenn die zu verarbeitenden Vektoren nur 128 Bit groß sind. Geht zwar meist irgendwie (arbeitet man eben zwei Vektoren in einem Schritt ab statt nur einen), ist aber fummelig.
Ich habe keine Quelle, habe es nur gehört von Opteron von Planet3DNow!, dass eine dritte Integer-Pipe im Schnitt nur 5% mehr IPC bringen soll.
Was natürlich aufs Problem ankommt. Wenn man irgendwelche Hashfunktionen berechnet, zieht ein Phenom mit 6x3 Integer-Pipelines auch schonmal an Haswell mit 4x4 vorbei.
Auf der anderen Seite habe ich auch Code hier, der auf Steamroller im Schnitt mehr als drei Befehle pro Takt schafft, weil eben nicht nur die ALUs zur Integer-Leistung beitragen, sondern a) Register-to-Register-Moves im Frontend eliminiert werden und keine ALU-Ressourcen mehr brauchen, b) die beiden Load/Store+AGU-Einheiten auch noch etwas Arbeit erledigen, nämlich eben bei Speicherzugriffen, und c) bis zu vier Befehle pro Takt durchs Frontend kommen statt nur drei.
Bulldozers Integer-Schwäche rührt mE aber auch eher von ewig langen L2-Latenzen und langen Branch Misprediction Penalties her.
Beispiel: Compiler. Wenn ich ein Programm mit clang compiliere, kommen auf dem Phenom in der Regel IPC-Werte von ca. 0.75 ±0.05 heraus, auf meinem Kaveri-Notebook lediglich ~0.6. Bei solchen Zahlen sollte klar sein, dass es wohl
nicht die drei Integer-Einheiten sind, die dem Phenom da zum Sieg verhelfen.
Die L1-Caches gelten auch als sehr klein, bleiben aber unverändert.
Intel hat auch nur 32kB für zwei Threads. Solange der von einem schnellen L2 mit niedrigen Latenzen und hoher Bandbreite gefüttert wird, ist das kein großes Problem - Zitat Anandtech anno 2009:
L2: It's the new L1 - BDs L2 ist latenzmäßig aber kaum besser als Intels L3, da fehlt quasi eine ganze Abstufung.
Obwohl Kern 7,8 und 9 theoretisch 2,8 Ghz schaffen würden kann man den Gesamtprozessor nur mit der Taktrate des schlechtesten Kerns, also Kern eins, mit 1,9 Ghz ausliefern.
Zumindest bei AMDs K10 hat jeder Kern separate VID- und FID-Tabellen, das ginge theoretisch also auch jetzt schon. Es wäre nur a) marketingtechnisch schwer zu vermitteln, warum man so ein Konzept wählt, und b) softwaretechnisch schwierig, weil ein Task-Scheduler die Geschwindigkeit jedes einzelnen Kerns kennen
und SMT-Aware sein müsste.
