Im Vorfeld des "Vishera"-Starts gab es oft Irrungen und Wirrungen um die Version der verbauten "Piledriver"-Kerne. Merkwürdig war unter anderem die Einordnung der CPU als Modell 2. Denn dadurch waren alle Verbesserungen, die für Trinity und dessen Piledriver-Kerne ab Modell 10 beschrieben wurden, per Definition in AMDs Software Optimization Guide nicht gültig. Ein weiterer Kritikpunkt war die Bezeichnung des Silizium-Dies, welches AMD-intern weiterhin unter dem Namen "Orochi" läuft. Dies ist die gleiche Bezeichnung, die bereits für die alten FX-CPUs gebräuchlich war, womit "Vishera" quasi nur ein Update dieses Chips werden würde. Gegen beide Punkte sprach, dass "Vishera" eher nur kurzfristig als Übergangslösung geplant wurde, wodurch die aktuellen AMD-Informationen veraltet waren. Schließlich ersetzte "Vishera" die "Komodo"-CPU, die ursprünglich einmal für Trinitys FM2-Sockel geplant war. Im Folgenden wollen wir dem Ganzen nun auf den Zahn fühlen:

Erste Unterschiede, dass nicht alles "Piledriver" ist, was "Piledriver" heißt, sieht man in den offiziellen Informationen von AMD. Bei "Trinity" wurden die "Piledriver"-Verbesserungen noch folgendermaßen illustriert:


Trinity-Piledriver Verbesserungen

Bei "Vishera" nun, sieht das Ganze so aus:

Vishera-Piledriver Verbesserungen

Wie man auf den ersten Blick sieht, fehlt dem "Vishera"-Derivat die Unterstützung für größere Instruktions-Pakete. Während "Trinity" die vollen 32 Byte eines Rohpaketes in ein 32-Byte-Paket lädt, verteilen "Zambezi" und "Vishera" die 32 Byte des Rohpakets in zwei 16-Byte-Pakete. Dies ist vermutlich auch der Grund, wieso wir in einer früheren News-Meldung Unterschiede im Front-End des Chips ausmachen konnten, die wir damals noch der Sprungvorhersage zuordneten.

Zum Glück bewahrheitete sich unsere damalige Schlussfolgerung aber nicht, abgesehen von der verbesserten Integer-Divisions-Einheit (wir berichteten) sind auch alle restlichen Verbesserungen der "Piledriver"-Kerne mit an Bord. Im obigen Foto taucht gar ein zusätzliches Feature auf, nämlich größere Puffer für Speicher-Lade-Befehle. Diese sind allerdings auch im Software Optimization Guide für "Trinity" aufgeführt und stellen somit keinen Unterschied dar.

Als Zwischenfazit können wir also festhalten, dass "Visheras" CPU-Kerne fast identisch zu "Trinitys" sein sollten und nur geringe Unterschiede (im Front-End) bestehen. Die "Piledriver"-Bezeichnung geht somit also schon in Ordnung. Ein Restzweifel bleibt aber wegen dem Informationschaos natürlich trotzdem noch. Deswegen verfahren wir nach dem guten, alten Motto: Vertrauen ist gut – Kontrolle ist besser, und überprüfen AMDs Angaben aus der obigen Hochglanzfolie so gut wie möglich.

Integer-Divisions-Einheit
Am einfachsten ist die Überprüfung des Integer-Dividierers. Dafür starteten wir einfach den Passmark-Test, den wir in der bereits oben erwähnten Meldung verwendeten, da der Integer-Code übermäßig viele Divisionen aufwies. Die Resultate sprechen für sich und bedürfen keiner weiteren Erläuterung:


Der "Vishera" liegt weit vor allen anderen Chips. Die Integer-Dividier-Einheit muss also aktiv sein, da sich ohne Aktivierung das hervorragende Ergebnis nicht erklären ließe.

Larger L1 TLB
Als nächstes überprüften wir die vergrößerten L1-TLBs. Diese werden benötigt, um die Speicheradressen schnell zwischen logischen und physikalischen Adressen umrechnen zu können. Eine kurze Erklärung der Funktionsweise findet man auf Wikipedia. Kurz gesagt, die TLBs sind quasi ein Cache, der die letzten benutzen Adressen zwischenspeichert. Die alten FX-Chips mit den Bulldozer-Kernen hatten nur eine Kapazität von 32 Einträgen, jetzt sollen es 64 sein. Den ersten Beweis dafür erhält man, wenn man sich vom Prozessor selbst über seine Fähigkeiten informieren lässt, denn für die Größe der TLB-Einträge gibt es CPUID-Melde-Register. Bei den alten FX-Chips erfuhr man auf eine Anfrage noch folgenden Zahlen-Wust:

Nun, bei den Piledriverkernen, erhält man aber:

Also "40" anstatt 20 in der ersten Version. Diese "40" sind in Hex-Code angegeben, bedeuten also im Dezimalsystem 64, während die "20" auf 32 Einträge verwiesen. Laut den prozessoreigenen Registern sind somit also wirklich mehr TLB-Einträge im "Vishera" zu finden. Sicherheitshalber haben wir aber auch noch mit Rightmarks Memory Analysator (RMMA) nachgemessen. Zum Vergleich mit anderen AMD-CPUs sind neben unserem "Vishera"-Testexemplar FX-8350 auch noch ein K10, ein FX-8150 und ein A10-5800K ("Trinity") zu finden. Da es bei den Messungen nur um Takte bzw. Einträge geht, spielen die unterschiedlichen Frequenzen der Chips keine Rolle.

AMD Vergleich: D-TLB Messung bis 511 KiB

Wie man sieht, liegt der alte K10 mit 48 Einträgen schön zwischen dem FX-8150 und den Piledriver-Versionen ("Trinity" und "Vishera"). Unschön dagegen ist die gestiegene Latenz des L2-TLBs, der im Vergleich zum "Zambezi" nun über 30 Takteinheiten liegt. Womöglich hat dies aber nur einen kleinen Seiteneffekt, die verdoppelten L1-TLBs wiegen den kleinen Nachteil sicherlich durch einen höheren Vorteil auf.

Stichwort Vorteil, was hat man nun konkret davon? Antwort: Vor allem eine bessere Ausnutzung der L1- und L2-Caches. Zwar haben die FX-Chips einen großen 2 MiB L2-Cache, jedoch sind dessen Zugriffszeiten davon abhängig, ob die Zugriffsmuster geordnet oder chaotisch sind. Normale Wald- und Wiesen-Messprogramme messen normalerweise nur geordnete Zugriffe, die immer Bestwerte erzielen. Bei RMMA kann man dagegen auch einen chaotischen Zugriff mittels Zufallszugriffen simulieren. In diesem Fall steigt die L2-Latenz bereits ab nur 128 KiB relativ stark an, was den Effekt des großen L2-Caches mindert. Mit 64 Einträgen des L1-TLBs verdoppelt sich nun der Spielraum aber immerhin auf 256 KiB. Zwar noch immer etwas wenig, aber bei einer Verdoppelung kann man sich schlecht beschweren. Im folgenden Cache-Zugriffs-Diagramm haben wir wieder die AMD-Riege gegen den FX-8350 antreten lassen:


AMD D-Cache-Vergleich bis 512 KiB (Zufallszugriffe)

"Vishera" verschwindet hier komplett hinter der Trinity-Farbe, wie es sich für einen "Piledriver"-Chip gehört. Das alte K10-Design schlägt im Bereich bis 511 KiB zwar alles (zuerst mit 3 Takten L1-Zugriff und dann mit ~15 Takten für den L2-Zugriff), jedoch steigt die Kurve im abgeschnittenen Bereich dann deutlich an.

Sonstige Verbesserungen
Die weiteren Verbesserungen sind leider nicht so einfach nachzuweisen. Eine bessere Sprungvorhersage verbessert z.B. – wie viele andere Optimierungen auch – "nur" die Leistung pro Watt. Trotzdem konnten wir mittels RMMA noch weitere Verbesserungen feststellen, welche vermutlich auf die größeren Scheduler und Lade-/Speicher-Operations-Verbesserungen beruhen. Beim Decoding-Test mittels eines sechs Byte langen CMP-Befehls steigt die Ausführungsrate von 3,6 Bytes/s auf 4,8 Byte/s, falls die Daten im L2-Cache liegen. Dies können wir im nächsten Diagramm sehen:


AMD Dekodervergleich bis 16 MiB

Auch in diesem Test versteckt sich unser "Vishera"-Exemplar. Zuerst hinter der Kurve des Trinity, und dann ab 2 MiB hinter der "Zambezi"-Kurve, da diese beiden CPUs als einzige über 8 MiB L3 verfügen.

XOR/ADD
Einen ähnlichen Effekt gibt es beim XOR/ADD-Decode-Test von RMMA. Fiel der FX-8150 nach den 64 KiB des L1I-Caches noch etwas ab, schafft "Vishera" die gleiche Rechenleistung bis zum Ende des 2 MB großen L2-Caches.


AMD XOR/ADD Dekoder-Vergleich bis 16 MiB

Wieder überdecken "Trinity" und "Zambezi" unseren "Vishera", nur um ~4 MiB kann man ihn erahnen. Außerdem sieht man, dass vier Byte pro Taktzyklus im Vergleich zum alten K10 eher schlecht sind, da dieser sechs Byte pro Takt verarbeiten kann. Hier liegt eine Back-End-Limitierung vor, d.h. ein Limit, dass durch das Verkleinern der Integer-Rechenwerke von drei auf zwei Pipelines von K10 auf Bulldozer auftrat. Nicht der Dekoder, Cache oder Speicher limitieren in diesem Fall, sondern schlicht die begrenzten Rechenressourcen. Die AMD-CPUs ab Modellnummer 20 sollten diesen Umstand beheben, da dort erstmals der XOR-Befehl auch von den AGUs berechnet werden kann (wir berichteten). Vermutlich handelt es sich bei den Modellnummern 20 um Chips mit Steamroller-Kernen.

Clock-Mesh
Eine andere Neuerung, nämlich das resonant Clock-Mesh, welches bei Trinity eingesetzt wird, ist laut Aussagen von AMD nicht in "Vishera" enthalten. Trotzdem konnte der Basistakt aber um 400 MHz gesteigert werden.

"Piledriver"-Fazit
Zwar sind es keine 100%-igen Piledriverkerne, jedoch weisen Visheras Piledriverkerne ebenfalls eine Menge von Verbesserungen auf, sodass wir gespannt zu den Praxistests übergehen können.