AMD Ryzen 7 1800X Review – Teil 1
AMD Ryzen – Die Architektur im Detail: Bessere Kernarchitektur
Als erstes fällt auf, dass AMD überall mehr investiert. Neben neuen Kernelementen wie dem energiesparenden Stack-Cache oder dem µOp-Cache gibt es zahlreiche bekannte Rechenwerke (8 an der Zahl plus 2 Adressgenerierungseinheiten), zu denen sich besonders tiefe Puffer gesellen:
- Instruktionsscheduler:
- Integer: 84 (48 bei Bulldozer: “BD”)
- FP: 96 (60 bei BD)
- größere Retire-Bandbreite: 8 µOps pro Takt anstatt 4 µOps (BD)
- größere Retire-Puffer: 192 statt 128 Einträge (BD)
- größerer Ladepuffer: 72 statt 44 Einträge (BD)
- größerer Speicherpuffer: 44 statt 32 Einträge (BD)
Die Zählweise bei den Integerschedulern ist etwas optimistisch. Genaueres folgt in der Detailbetrachtung des Integer-Rechenwerkes.
Auffallend ist die Erweiterung der Retire-Möglichkeiten, deren Umfang gleich verdoppelt wurde. In diesem letzten Schritt werden alle ausgeführten Befehle gesammelt, wieder in die richtige Befehlsreihenfolge gebracht und abgeschlossen. Alle Kniffe wie die Ausführung außerhalb der Befehlsreihenfolge (Out-of-Order-Execution alias OoO) werden also rückgängig gemacht. AMD gibt an, dass Bulldozer hier einen Flaschenhals aufwies. Vier Befehle pro Takt waren zu wenig, da in diesem finalen Schritt nicht nur OoO, sondern auch Tricks wie Macro-Op-Fusion oder Move-Elimination rückgängig gemacht werden müssen. Bei Zen gibt es jetzt 8 Retirement-Möglichkeiten pro Takt, diese dürften in jedem Fall – auch noch für 2 Threads – ausreichend sein.
Zweiter Punkt in AMDs Übersicht ist das Cachesystem, welches wir auf den nächsten Seiten vorstellen möchten.
Zuallererst sieht man auf AMDs Übersicht auf der vorhergehenden Seite, dass wiederum verbreitert und verbessert wurde:
- Write-Back-L1-Cache
- schnellerer L2-Cache
- schnellerer L3-Cache
- schnelleres Laden in die FPU: 7 statt 9 Zyklen
- bessere L1- and L2-Daten-Prefetcher
- fast doppelte L1- und L2-Bandbreite
- fast verfünffachte L3-Gesamtbandbreite
Zunächst springt ins Auge, dass AMD zu einem L1-Cachedesign zurückgekehrt ist, wie es früher üblich war: Berechnete Daten werden nur in den L1-Cache zurückgeschrieben (write back), ohne die höheren Cache-Ebenen zu strapazieren. Grund hierfür war Mike Clark zufolge vor allem der Stromverbrauch. Zwar lässt ein Write-Through-Cache wie bei Bulldozer höhere Taktraten zu, allerdings muss man die Daten auch direkt in den L2-Cache schreiben, was energieaufwändig ist. Will man also keine CPUs mit einer TDP um 220 Watt mehr konstruieren, ist Write-Back die einzig sinnvolle Variante.
Die L1-Caches sind 32 KiB (Daten) sowie 64 KiB (Instruktionen) groß und werden von 512 KiB L2 sowie 8 MiB L3 unterstützt. Dies war schon seit letzter Woche bekannt:
Interessant wird es nun bei den Details. Die Latenz dieser Write-Back-Caches, wie einer als L1-Datencache dient, beträgt gemäß AMD vier Takte. Bzgl. der L2- wie L3-Cachelatenzen bleibt AMD uns leider genauere Angaben schuldig und gibt nur die unscharfe Information preis, dass diese “schneller” wären.
Pi mal Daumen und mit der aufgesetzten dunkelgrünen Brille optimistisch geschätzt, dürften sich die Latenzen bei weniger als 15 Takten (L2) und etwas über 30 Takten (L3) bewegen. Letzterer wird wie Bulldozer in einer gesonderten Taktdomäne betrieben, sodass die Latenzen, die in Kerntakten gerechnet werden, entsprechend schlechter ausfallen können. Dies war bei Bulldozer ähnlich und selbst Intel wendet die gleiche Technik seit der Skylake-Architektur an. Dessen L3-Latenzen betragen im schlimmsten Fall sogar über 40 Takte. Da AMD jedoch das simplere Cache-Design (kein Ringbus) verwendet, sollte am Ende ein kleiner Vorteil für AMD übrig bleiben.
Die Zugriffszeiten von Zens L3-Caches unterscheiden sich Clark zufolge je nach Cachesegment und anfragendem Kern, da der L3 aus acht Teilen zu je einem MiB aufgebaut ist. Nahe gelegene L3-Segmente eines Kerns liefern die Daten naturgemäß etwas schneller als weiter entfernte. Der Unterschied dürfte hierbei nur wenige Takte betragen. Den Aufbau eines Zen-Quad-Moduls kann man auf dem nächsten Bild begutachten:
Man erkennt deutlich die acht 1‑Megabyte-Blöcke des L3, die jeweils von 512 KiB L2 pro Kern flankiert werden.
AMD wird diesen Quad-Modul-Kernbauplan für alle im Moment angekündigten Chips beibehalten. Das bedeutet also, dass erstens die 8‑Kern-Version “Summit Ridge” über 2x 8 MiB = 16 L3-Cache verfügen wird und zweitens auch die Zen-APUs mit GPU-Teil und nur einem Zen-Quad-Modul erstmals ebenfalls über einen L3-Cache verfügen werden.
Entgegen anderslautender Gerüchte setzt AMD beim Cache-Aufbau weiterhin auf exklusive L3-Caches nach der “Victim Strategy”. Das heißt, dass Daten in der Regel entweder direkt in den L1- oder in den L2-Cache geladen werden: Fallen Daten aus dem L2 heraus, landen diese “Opfer” (victims) im L3. Bei Intel-Designs liegen L2-Daten dagegen automatisch immer als Kopie auch im L3, was einerseits die effektive L3-Cachegröße und damit indirekt auch die L2-Größe begrenzt, andererseits die Kern-zu-Kern-Kommunikation vereinfacht.
Cache-Organisation und ‑Aufbau gehen somit Hand in Hand. Weil AMD kein inklusives Cachedesign wählte, ein Datenaustausch über den L3 also ohnehin fast unmöglich ist, benötigt man auch keinen einzelnen gemeinsamen L3-Cache, sondern kann sich mit simplen 8‑MiB-Modulen begnügen. Insbesondere bei Serverchips mit vielen Kernen und noch mehr Cache, wird die Cacheorganisation zum Problem. AMD setzt bei den Serverchips aber auch auf einen bewährten MCM-Ansatz, mit dem von vorne herein keine gemeinsamen L3-Caches möglich wären. Somit ist die Designentscheidung insgesamt nachvollziehbar und schlüssig. Als Speichermodell findet die bewährte und schon von K8/K10 bekannte MOESI-Strategie Anwendung.