Zen 2 — AMD Ryzen 7 3700X und Ryzen 9 3900X im Test
Technische Details: Kerne, Caches, FPU, Integer
Bereits von der letzten AMD-Architektur namens Bulldozer hin zu Zen konnte AMD eine mittlere Leistungssteigerung pro Takt (“IPC”) von 52 Prozent erreichen, nachdem 40 Prozent die ursprüngliche Design-Vorgabe waren. Das ist ein enormer Sprung! Manchmal mag man sich fragen, ob nicht irgendwann einmal ein Limit erreicht ist, nachdem das nun schon seit Jahrzehnten so geht. Aber anscheinend sind wir noch nicht so weit, denn für Zen 2 stellt AMD abermals eine IPC-Steigerung von ca. 15 Prozent in Aussicht. Wir zeigen auf diesen Seiten, woher diese kommen soll.
L0-Cache
Mit der Einführung von Zen brachte AMD ein Design-Element zur Anwendung, das bisherige AMD-Architekturen noch nicht genutzt hatten, bei Intel aber seit dem Pentium 4 (Trace-Cache), spätestens seit Sandy Bridge in der heutigen Form zum Einsatz kam: ein Micro-Op-Cache. Dieser Cache, manchmal auch L0-Cache genannt, hält fertig dekodierte Befehle vor, die von den Recheneinheiten sofort ausgeführt werden können, ohne zuvor noch einmal aus den x86-Befehlen dekodiert werden zu müssen. Das entlastet den Dekoder und spart Strom. Anscheinend hat sich das Konzept bewährt, denn AMD hat den Cache gegenüber Zen 1 gleich mal auf 4K Instruktionen verdoppelt.
L3-Cache
Verdoppelt hat AMD auch die Größe des L3-Cache. Das ist eine oft praktizierte Vorgehensweise, wenn sich durch Verkleinerung der Fertigungsstrukturen – hier 12 nm auf 7 nm – Spielräume ergeben, die eingesparte Die-Fläche möglichst günstig in mehr Leistung zu reinvestieren. Da bieten sich die Caches natürlich an, da an dieser Stelle zum einen kaum Entwicklungsaufwand anfällt und zum anderen Cache ohne weiteres Zutun der Software-Entwickler zu mehr Leistung führt. Die Mehrleistung gibt’s hier automatisch, auch für ältere Software, die nicht mehr z.B. an neu eingeführte SIMD-Befehle angepasst wird. Da AMD die Core-Complex-Bauweise beibehalten hat (CCX), stehen je 4 Kernen nun nicht mehr 8 MiB, sondern 16 MiB L3-Cache zur Verfügung. Je Die kommt AMD damit nun auf 32 MiB L3-Cache.
L1-Cache
Auch tiefer im Kern, an den L1-Caches, hat AMD geschraubt. Während Zen 1 noch einen L1-Instruction-Cache von 64 KiB aufwies, muss Zen 2 nun mit 32 KiB auskommen. Natürlich verkleinert man einen Cache normalerweise nicht ohne Hintergedanken. Kleinere Caches können eine kürzere Latenz aufweisen, wenn sie entsprechend konzipiert sind. Zudem hat AMD als Gegenmaßnahme die Assoziativität von 4‑way auf 8‑way verdoppelt, was den Cache flexibler und effizienter nutzbar macht. Zudem dürfte bei der Designüberlegung auch der vergrößerte Micro-Op-Cache eine Rolle gespielt haben. Während der L1-Instruction-Cache x86-Befehle vor dem Dekoder puffert, hält der Micro-Op-Cache die bereits dekodierten RISC-ähnlichen Befehle vor. Das verringert den Druck auf den Dekoder und damit auch auf den L1-I-Cache, weswegen AMD hier Fläche sparen konnte ohne groß Leistung einzubüßen.
Wie bei jeder Architekturüberarbeitung darf auch bei Zen 2 der Passus “improved branch prediction” nicht fehlen. Die Sprungvorhersage zu verbessern muss auch Ziel einer modernen Out-of-Order-Architektur mit hohen Taktfrequenzen und damit relativ langen Pipelines sein, denn derartige Prozessoren spekulieren, wohin die Reise im Fortlauf des Codes gehen könnte und warten nicht ab, bis die Entscheidung “Sprung ja oder nein” im Code wirklich feststeht. Stattdessen arbeiten sie Programmzweige schon auf Verdacht ab und verlassen sich dabei auf die Sprungvorhersage. Lag sie richtig, hat der Prozessor schon jede Menge Arbeit vorab auf Verdacht erledigt und damit Rechenzeit eingespart, wo ein In-Order-Prozessor erst jetzt anfangen würde zu rechnen. Teuer wird es jedoch wenn die Sprungvorhersage falsch lag. Dann müssen alle vorab erledigten Sachen rückgängig gemacht, Ergebnisse verworfen und die Pipeline geleert werden. Ein solcher Pipeline-Flush dauert etliche Takte und der gesamte Ablauf kommt ins Stocken, sodass eine Sprungvorhersage mit möglichst hoher Trefferquote unabdingbar ist. Wie hoch sie bei Zen 2 liegt, verrät AMD leider nicht – üblich sind mittlerweile jedoch weit über 90 Prozent – nur, dass die Wahrscheinlichkeit, daneben zu liegen, um 30 Prozent reduziert worden ist. Nach eigenen Angaben setzt AMD bei Zen 2 einen TAGE Branch Predictor ein.
Mit der Sprungvorhersage einher gehen die Verbesserungen des Branch Target Buffer (BTB). Auch hier hat AMD gefeilt und den L1BTB auf 512 Einträge verdoppelt und den L2BTB von 4K auf 7K vergrößert.
Ein massiver Umbau wurde an der Fließkomma-Einheit (FPU) vorgenommen: AMD hat die Breite der FPU glatt verdoppelt. 256 Bit können nun auf einen Rutsch verarbeitet werden, wohingegen bis einschließlich Zen 1 derart breite Zahlen auf zwei 128-Bit-Berechnungen aufgeteilt werden mussten. Die letzte Vergrößerung der FPU-Breite ist schon eine Weile her. Beim Wechsel von K8 auf K10 im Jahr 2007 wurde hier zuletzt Hand angelegt, als es von 64 Bit auf 128 Bit ging. So ein grundlegender Designschritt will gut überlegt sein, denn er kostet Fläche und natürlich gibt es die höhere Leistung auch in Sachen Stromverbrauch nicht umsonst. Zudem nutzen nur AVX/AVX2-Befehle derart breite Datentypen, sodass folglich auch nur solche Berechnungen davon profitieren. Anscheinend hat AMD entschieden, dass nun die Zeit reif dafür ist und mittlerweile genügend Anwendungen AVX nutzen, damit sich eine aufwändigere FPU lohnt. Wir werden das natürlich später bei den Benchmarks im Auge behalten.
Neben der FPU hat auch die Integer-Einheit einiges an Feinschliff erfahren. Diverse vergrößerte Puffer sowie verlängerte Warteschlangen sind obligatorisch bei Shrinks. Aber dabei blieb es nicht. AMD hat Zen 2 eine zusätzliche Address Generation Unit (AGU) spendiert, sodass nun insgesamt 7 (statt 6) Befehle gleichzeitig ausgeführt werden können, sofern der Befehlsmix genau zur Anzahl der Einheiten passt. Zudem soll AMDs Implementierung von Simultaneous Multithreading (SMT) verbessert worden sein und zu weniger Locks führen, was den Gesamtdurchsatz verbessern soll.
Bezüglich Load/Store hat AMD offenbar einige Flaschenhälse im Kern geweitet. Nicht nur die Latenz beim Zugriff auf den L2 DTLB soll verkürzt worden sein, auch die Bandbreite wurde an mehreren Stellen erhöht, beim L1 glatt verdoppelt, sodass die breiteren Rechenwerke auch schnell genug mit Daten versorgt werden können und nicht leerlaufen. Dank der höheren Transferrate können auch die Prefetcher etwas größzügiger agieren ohne dabei die “normalen” Transfers zu bremsen.
Vom Cache-Aufbau her bleibt alles beim alten. Der L2-Cache ist unified, trägt also Daten und Instruktionen und steht jedem Kern “privat” in 512 KiB Größe zur Verfügung. Der L3-Cache – nun in doppelter Größe vorhanden – ist weiterhin ein Victim-Cache des L2. Das heißt, im L3-Cache landet das, was vorher aus den L2-Caches herausgefallen ist, in der Hoffnung, dass es im weiteren Programmverlauf nochmal benötigt wird. Durch diese Design-Philosophie liegen Daten – anders als bei Intel – niemals gleichzeitig in L2- und L3-Cache.
