AMD Zen 3 Architektur im Detail

Änderungen – Front-End und Load/Store

Nicht nur bei der Kom­mu­ni­ka­ti­on zwi­schen ein­zel­nen Ker­nen, auch bei der Ver­ar­bei­tung inner­halb eines Kerns hat AMD ver­sucht, Laten­zen abzu­fei­len und Tot­zeit zu redu­zie­ren. So pro­kla­miert AMD einen schnel­le­ren Branch Pre­dic­tor, ein schnel­le­res Umschal­ten zwi­schen Op-cache und Ins­truc­tion Cache, eine höhe­re Tref­fer­quo­te des Branch Pre­dic­tors und eine kür­ze­re Reco­very Zeit falls der Pre­dic­tor falsch gele­gen hat. Ins­ge­samt war das Design­ziel laut AMD, die Fetch­pha­se zu ver­kür­zen, ins­be­son­de­re bei Code, der vie­le Sprün­ge ent­hält und auf­grund der Grö­ße auf Pre­fetch ange­wie­sen ist.

Wie schon bei Zen 2 setzt AMD auf einen TAGE Branch Pre­dic­tor. Aller­dings arbei­tet die­ser laut AMD nun bei den meis­ten Vor­her­sa­gen mit “Zero Bubble”, also ohne Ver­zö­ge­rung beim Aus­le­sen des Branch Tar­get Buf­fers (BTB), an wel­cher Adres­se denn nun der nächs­te Befehl zu fin­den ist. Über­haupt hat AMD am BTB ordent­lich Hand ange­legt. der L1BTB ist mit 1024 Ein­trä­gen glatt dop­pelt so groß wie bei Zen 2 und vier Mal so groß wie bei Zen 1. Dafür muss­te der L2TLB mit 6500 vs. 7000 Ein­trä­gen etwas Federn lassen.

Beim Lesen und Schrei­ben von Daten (Load/Store) hat AMD eben­falls opti­miert. Die Store Queue hat nun 64 Ein­trä­ge gegen­über 48 zuvor. Ins­ge­samt sol­len grö­ße­re Struk­tu­ren vor­ge­la­den wer­den kön­nen, um Abhän­gig­kei­ten bes­ser auf­lö­sen zu kön­nen und mehr Ins­truc­tion Level Par­al­le­lism (ILP) zu errei­chen, um die Aus­füh­rungs­ein­hei­ten bes­ser aus­las­ten zu kön­nen. Dazu wur­de die Trans­fer­ra­te der Loa­d/S­to­re-Ein­hei­ten ver­grö­ßert und fle­xi­bler gestaltet.