Details und Analyse der Zen-Architektur nach der Hot-Chips-Konferenz

Artikel-Index:

Die Fetch-Einheit im Detail

Um die bereits gezeig­ten Res­sour­cen für Aus­füh­rung und Daten­hal­tung nicht ver­hun­gern zu las­sen, hat AMD auch das soge­nann­te Exe­cu­ti­on Front End, also die Befehls­ver­sor­gung, gegen­über Exca­va­tor aus­ge­baut.

Das beginnt mit in drei Ebe­nen vor­han­de­nen gro­ßen Adress­über­set­zungs-Spick­zet­teln (Trans­la­ti­on Looka­si­de Buf­fers oder TLBs), die sowohl schnell als auch in die­ser Kom­bi­na­ti­on ener­gie­spa­rend sind. Dort wer­den ein­mal die Über­set­zun­gen von vir­tu­el­len in phy­si­ka­li­sche Adres­sen von Spei­cher­blö­cken mit Pro­gramm­code für den Schnell­zu­griff vor­ge­hal­ten. Treue Leser wer­den sich an die TLB-Pro­ble­me der ers­ten Bull­do­zer­ver­si­on und deren Ver­bes­se­run­gen ab Vis­he­ra erin­nern.

Eben­so erwäh­nens­wert ist der Hash Per­cep­t­ron Pre­dic­tor, also eine Sprung­vor­her­sa­ge-Ein­heit, die mit Hil­fe eines neu­ro­na­len Net­zes das Sprung­ver­hal­ten im aus­ge­führ­ten Pro­gramm­code lernt und vor­her­sagt. Das hat­ten auch schon die Cat-Ker­ne und spä­te­re Ker­ne der Bull­do­zer-Rei­he. Bei Zen wird gibt es jedoch die Neue­rung, dass das mit Hash­es ver­knüpft wird, um die Leis­tung noch zu stei­gern. Dabei bestimmt nicht allein die aktu­el­le Posi­ti­on im Pro­gramm­code, wel­ches Per­cep­t­ron zustän­dig ist, son­dern es wird aus der Adres­se und deren bis­he­ri­gen Sprung­his­to­rie ein Hash berech­net. Das erhöht die Tref­fer­quo­te noch­mals.

Der 32 Ein­trä­ge gro­ße Return Stack Puf­fer ist wich­tig für die immer tie­fer ver­schach­tel­ten Auf­ru­fe heu­ti­ger Soft­ware und Betriebs­sys­te­me. Das Indi­rect Tar­get Array unter­stützt dage­gen z. B. bei vir­tu­el­len Funk­ti­ons­auf­ru­fen oder Sprung­ta­bel­len in Switch-Case-Anwei­sun­gen (für die Pro­gram­mie­rer unter uns).

Der mit 64 KiB (4-wegig) aus­rei­chend dimen­sio­nier­te Level-1-Befehls­cache soll­te auch mit zwei Threads im SMT-Betrieb nicht so schnell Eng­päs­se auf­kom­men las­sen. Bei der Bull­do­zer-Rei­he, wo das Front End eben­falls zwei Threads abar­bei­ten konn­te, betrug die Grö­ße die­ses Cache anfangs auch 64 KiB (indes nur 2-wegig), wel­che spä­ter auf 96 KiB (3 Wege) ab Steam­rol­ler auf­ge­stockt wur­den. Zudem gibt es bei Bull­do­zer im Zusam­men­spiel mit einem Linux-Sicher­heits­fea­ture (ASLR) Pro­ble­me, wo der im Cache lie­gen­de Pro­gramm­code bei bestimm­ten Kom­bi­na­tio­nen von Spei­cher­adres­sen zwei­er oder meh­re­rer Pro­gram­me gegen­sei­tig wie­der aus dem Cache gewor­fen wur­de.

Nach­dem eine Adres­se ermit­telt und in die Phy­si­cal Request Queue für das Laden des nächs­ten Pro­gramm­codes aus dem Level-1-Befehls­cache ein­ge­reiht wur­de, wird par­al­lel über ein klei­nes Tag (µTag) geprüft, ob die gewünsch­ten Befeh­le schon im MOp-Cache vor­lie­gen. Lie­fert das µTag für den MOp-Cache kei­nen Tref­fer, wer­den die Befeh­le in einem 32 Byte-Block aus dem L1-Befehls­cache gela­den und an die Deco­der-Ein­heit wei­ter­ge­reicht.

« Die Lade-/Spei­cher­ein­hei­ten im Detail» Die Deco­der-Ein­heit im Detail