AMD Piledriver vs. Steamroller vs. Excavator — Leistungsvergleich der Architekturen

2nd Generation: Piledriver

(Auszug/Zusammenfassung aus dem Arti­kel vom 01.05.2012)

Bei der APU Tri­ni­ty wur­de erst­mals die 2. Gene­ra­ti­on der Bull­do­zer-Archi­tek­tur namens Piledri­ver ein­ge­setzt. Vie­le Ein­zel­hei­ten, wie z.B. der grö­ße­re TLB, die grö­ße­ren Sche­du­ler-Win­dows, Befehls­satz­er­wei­te­run­gen wie FMA3 und F16C, zusätz­li­che Wri­te Buf­fer für den L2, die IDIV-Ein­heit oder die Auf­he­bung des Straf­zolls für 256-Bit-AVX-Befeh­le waren schon vor­her durch den AMD Opti­miza­ti­on Gui­de oder durch eige­ne Recher­che bekannt, die durch den aktu­el­len Foli­en­satz bestä­tigt wur­den. Das Front-End, in dem die Daten in ein Bull­do­zer-Modul ein­ge­le­sen wer­den, sieht man in fol­gen­dem Bild:

Eini­ge Schwach­stel­len, die z.B. durch den Infor­ma­tik­pro­fes­sor Agner Fog ange­mahnt wur­den, waren damit beho­ben oder zumin­dest abge­mil­dert. (Eine Zusam­men­fas­sung der Schwach­stel­len gab es in unse­rer alten Mel­dung: Bull­do­zer-Archi­tek­tur unter der Lupe: Schwach­stel­len iden­ti­fi­ziert).

Eine der Schwach­stel­len war das soge­nann­te Ins­truc­tion Win­dow gewe­sen. Das ist ein Paket von x86-Befeh­len, das von der “Fetch-Unit” geschnürt wird und dar­auf war­tet, durch den Deko­der in inter­ne µOps deko­diert zu wer­den. Wie auch beim K10 wer­den beim Bull­do­zer 32 Byte pro Takt aus dem L1-Ins­truc­tion-Cache ein­ge­le­sen, aber bei Bull­do­zer tei­len sich die 32 Byte dann eben auf zwei Threads und damit auch auf zwei Ins­truc­tion Win­dows à 16 Byte auf. 16 Byte sind für AMD des­halb ein Rück­schritt. Aktu­el­le Intel-CPUs holen sich pro Takt zwar auch nicht mehr, aller­dings wird Intels Deko­der durch den Loop Stream Detec­tor (seit der Pen­ryn-Gene­ra­ti­on, ver­bes­sert im Neha­lem) und den gro­ßen µOp-Puf­fer (seit San­dy Bridge) stark ent­las­tet. Mit sol­chen Fines­sen kann auch Piledri­ver nicht auf­war­ten, aber immer­hin wird der Fla­schen­hals etwas gewei­tet. Zu guter Letzt darf man nicht ver­ges­sen, dass es wei­ter­hin nur einen Deko­der je Modul gibt. Das Maxi­mum bleibt also bei zwei x86-Instruk­tio­nen pro Takt und pro Thread, aber mit einem grö­ße­rem Ins­truc­tion Win­dow stellt man sicher, dass die­ses Maxi­mum öfter erreicht wer­den kann.

Zusätz­lich gab es im Front-End noch Fein­tu­ning an der Sprung­vor­her­sa­ge-Logik, die­se kann mehr Ein­trä­ge umfas­sen, was man auch im Die-Foto erken­nen kann.