AMD Ryzen 7 1800X Review – Teil 1

Artikel-Index:

AMD Ryzen – Die Architektur im Detail: Bessere Kernarchitektur

Als ers­tes fällt auf, dass AMD über­all mehr inves­tiert. Neben neu­en Kern­ele­men­ten wie dem ener­gie­spa­ren­den Stack-Cache oder dem µOp-Cache gibt es zahl­rei­che bekann­te Rechen­wer­ke (8 an der Zahl plus 2 Adress­ge­nerie­rungs­ein­hei­ten), zu denen sich beson­ders tie­fe Puf­fer gesellen:

  • Instruk­ti­ons­sche­du­ler:
    • Inte­ger: 84 (48 bei Bull­do­zer: “BD”)
    • FP: 96 (60 bei BD)
  • grö­ße­re Reti­re-Band­brei­te: 8 µOps pro Takt anstatt 4 µOps (BD)
  • grö­ße­re Reti­re-Puf­fer: 192 statt 128 Ein­trä­ge (BD)
  • grö­ße­rer Lade­puf­fer: 72 statt 44 Ein­trä­ge (BD)
  • grö­ße­rer Spei­cher­puf­fer: 44 statt 32 Ein­trä­ge (BD)

Die Zähl­wei­se bei den Inte­ger­sche­du­lern ist etwas opti­mis­tisch. Genaue­res folgt in der Detail­be­trach­tung des Integer-Rechenwerkes.

Auf­fal­lend ist die Erwei­te­rung der Reti­re-Mög­lich­kei­ten, deren Umfang gleich ver­dop­pelt wur­de. In die­sem letz­ten Schritt wer­den alle aus­ge­führ­ten Befeh­le gesam­melt, wie­der in die rich­ti­ge Befehls­rei­hen­fol­ge gebracht und abge­schlos­sen. Alle Knif­fe wie die Aus­füh­rung außer­halb der Befehls­rei­hen­fol­ge (Out-of-Order-Exe­cu­ti­on ali­as OoO) wer­den also rück­gän­gig gemacht. AMD gibt an, dass Bull­do­zer hier einen Fla­schen­hals auf­wies. Vier Befeh­le pro Takt waren zu wenig, da in die­sem fina­len Schritt nicht nur OoO, son­dern auch Tricks wie Macro-Op-Fusi­on oder Move-Eli­mi­na­ti­on rück­gän­gig gemacht wer­den müs­sen. Bei Zen gibt es jetzt 8 Reti­re­ment-Mög­lich­kei­ten pro Takt, die­se dürf­ten in jedem Fall – auch noch für 2 Threads – aus­rei­chend sein.

Zwei­ter Punkt in AMDs Über­sicht ist das Cache­sys­tem, wel­ches wir auf den nächs­ten Sei­ten vor­stel­len möchten.

Zual­ler­erst sieht man auf AMDs Über­sicht auf der vor­her­ge­hen­den Sei­te, dass wie­der­um ver­brei­tert und ver­bes­sert wurde:

    • Wri­te-Back-L1-Cache
    • schnel­le­rer L2-Cache
    • schnel­le­rer L3-Cache
    • schnel­le­res Laden in die FPU: 7 statt 9 Zyklen
    • bes­se­re L1- and L2-Daten-Prefetcher
    • fast dop­pel­te L1- und L2-Bandbreite
    • fast ver­fünf­fach­te L3-Gesamtbandbreite

Zunächst springt ins Auge, dass AMD zu einem L1-Cache­de­sign zurück­ge­kehrt ist, wie es frü­her üblich war: Berech­ne­te Daten wer­den nur in den L1-Cache zurück­ge­schrie­ben (wri­te back), ohne die höhe­ren Cache-Ebe­nen zu stra­pa­zie­ren. Grund hier­für war Mike Clark zufol­ge vor allem der Strom­ver­brauch. Zwar lässt ein Wri­te-Through-Cache wie bei Bull­do­zer höhe­re Takt­ra­ten zu, aller­dings muss man die Daten auch direkt in den L2-Cache schrei­ben, was ener­gie­auf­wän­dig ist. Will man also kei­ne CPUs mit einer TDP um 220 Watt mehr kon­stru­ie­ren, ist Wri­te-Back die ein­zig sinn­vol­le Variante.

Die L1-Caches sind 32 KiB (Daten) sowie 64 KiB (Instruk­tio­nen) groß und wer­den von 512 KiB L2 sowie 8 MiB L3 unter­stützt. Dies war schon seit letz­ter Woche bekannt:

Inter­es­sant wird es nun bei den Details. Die Latenz die­ser Wri­te-Back-Caches, wie einer als L1-Daten­cache dient, beträgt gemäß AMD vier Tak­te. Bzgl. der L2- wie L3-Cache­la­ten­zen bleibt AMD uns lei­der genaue­re Anga­ben schul­dig und gibt nur die unschar­fe Infor­ma­ti­on preis, dass die­se “schnel­ler” wären.

Pi mal Dau­men und mit der auf­ge­setz­ten dun­kel­grü­nen Bril­le opti­mis­tisch geschätzt, dürf­ten sich die Laten­zen bei weni­ger als 15 Tak­ten (L2) und etwas über 30 Tak­ten (L3) bewe­gen. Letz­te­rer wird wie Bull­do­zer in einer geson­der­ten Takt­do­mä­ne betrie­ben, sodass die Laten­zen, die in Kern­tak­ten gerech­net wer­den, ent­spre­chend schlech­ter aus­fal­len kön­nen. Dies war bei Bull­do­zer ähn­lich und selbst Intel wen­det die glei­che Tech­nik seit der Sky­la­ke-Archi­tek­tur an. Des­sen L3-Laten­zen betra­gen im schlimms­ten Fall sogar über 40 Tak­te. Da AMD jedoch das simp­le­re Cache-Design (kein Ring­bus) ver­wen­det, soll­te am Ende ein klei­ner Vor­teil für AMD übrig bleiben.

Die Zugriffs­zei­ten von Zens L3-Caches unter­schei­den sich Clark zufol­ge je nach Cache­seg­ment und anfra­gen­dem Kern, da der L3 aus acht Tei­len zu je einem MiB auf­ge­baut ist. Nahe gele­ge­ne L3-Seg­men­te eines Kerns lie­fern die Daten natur­ge­mäß etwas schnel­ler als wei­ter ent­fern­te. Der Unter­schied dürf­te hier­bei nur weni­ge Tak­te betra­gen. Den Auf­bau eines Zen-Quad-Moduls kann man auf dem nächs­ten Bild begutachten:

Man erkennt deut­lich die acht 1‑Me­ga­byte-Blö­cke des L3, die jeweils von 512 KiB L2 pro Kern flan­kiert werden.

AMD wird die­sen Quad-Modul-Kern­bau­plan für alle im Moment ange­kün­dig­ten Chips bei­be­hal­ten. Das bedeu­tet also, dass ers­tens die 8‑Kern-Ver­si­on “Sum­mit Ridge” über 2x 8 MiB = 16 L3-Cache ver­fü­gen wird und zwei­tens auch die Zen-APUs mit GPU-Teil und nur einem Zen-Quad-Modul erst­mals eben­falls über einen L3-Cache ver­fü­gen werden.
Ent­ge­gen anders­lau­ten­der Gerüch­te setzt AMD beim Cache-Auf­bau wei­ter­hin auf exklu­si­ve L3-Caches nach der “Vic­tim Stra­tegy”. Das heißt, dass Daten in der Regel ent­we­der direkt in den L1- oder in den L2-Cache gela­den wer­den: Fal­len Daten aus dem L2 her­aus, lan­den die­se “Opfer” (vic­tims) im L3. Bei Intel-Designs lie­gen L2-Daten dage­gen auto­ma­tisch immer als Kopie auch im L3, was einer­seits die effek­ti­ve L3-Cache­grö­ße und damit indi­rekt auch die L2-Grö­ße begrenzt, ande­rer­seits die Kern-zu-Kern-Kom­mu­ni­ka­ti­on vereinfacht.

Cache-Orga­ni­sa­ti­on und ‑Auf­bau gehen somit Hand in Hand. Weil AMD kein inklu­si­ves Cache­de­sign wähl­te, ein Daten­aus­tausch über den L3 also ohne­hin fast unmög­lich ist, benö­tigt man auch kei­nen ein­zel­nen gemein­sa­men L3-Cache, son­dern kann sich mit simp­len 8‑MiB-Modu­len begnü­gen. Ins­be­son­de­re bei Ser­ver­chips mit vie­len Ker­nen und noch mehr Cache, wird die Cache­or­ga­ni­sa­ti­on zum Pro­blem. AMD setzt bei den Ser­ver­chips aber auch auf einen bewähr­ten MCM-Ansatz, mit dem von vor­ne her­ein kei­ne gemein­sa­men L3-Caches mög­lich wären. Somit ist die Design­ent­schei­dung ins­ge­samt nach­voll­zieh­bar und schlüs­sig. Als Spei­cher­mo­dell fin­det die bewähr­te und schon von K8/K10 bekann­te MOE­SI-Stra­te­gie Anwendung.