AMD Bulldozer im Test: Ein schwarzer Mittwoch

„Back End“

Im Back End sind bei AMDs „Bulldozer“-Modul die beiden Integer-Kerne und die Gleitkomma-Einheit zu finden. Eine der grundlegenden Neuerungen ist auch dort ein Physical Register File (PRF). Bisher hatte jeder µOp (Micro-Befehl) eine Kopie seinesgleichen in einem Speicher abgelegt. Dadurch wurde immer Speicherplatz (und gleichzeitig auch Transferkapazität) belegt, welcher mit der Einführung des Physical Register Files anderweitig genutzt wird. Statt eine Kopie mitzuführen, wird der Micro-Befehl im PRF abgelegt und dort gezielt angesprochen. Um dies möglichst effektiv zu tun, stattet AMD sowohl die beiden Integer-Kerne als auch die Gleitkomma-Einheit mit derartigen Techniken aus. In den Integer-Kernen können so jeweils 96 Operanden zwischengespeichert werden, in der Gleitkomma-Einheit sind es 160 Operanden.

Kernstück der Integer-Kerne ist unter anderem die Lade- und Speichereinheit (Ld/ST Unit), die auf einen Puffer mit 40 Einträgen für Lade- und 24 Einträge für Speicher-Operationen zurückgreifen kann, während es der Phenom II noch auf insgesamt 44 Einträge (32 + 12) brachte. Beim K15 getauften „Bulldozer“ können in jedem einzelnen Integer-Kern allerdings zwei Lade- oder eine Speicheroperation pro Zyklus gleichzeitig durchgeführt werden, beim K10 war es nur einer.

Direkt an die Lade- und Speichereinheit sind die beiden AGUs und ALUs (Adressgenerierungseinheiten und Arithmetisch-logische Einheiten) gebunden. Jeweils eine ALU kümmert sich um die Division, die andere um die Multiplikation. Pro Modul sind es folglich vier AGUs und vier ALUs, was dem einzelnen Modul auf dem Papier gegenüber den Phenom-II-Kernen einen Vorteil bringt.

Um bei den Aufgaben zu helfen, verfügt jeder Integer-Kern über einen 16 KByte großen Daten-Cache. Dies stellt auf dem Papier eine massive Beschneidung zum Phenom II dar, waren es dort pro Kern noch 64 KByte. Weiterhin gibt es einen 32 Einträge fassenden Translation Lookaside Buffer (TLB) für Daten – früher waren es dort 48 Einträge.

Im Back End ist auch noch die Gleitkomma-Einheit zu finden, die wiederum als geteilte Einheit von beiden Integer-Kernen genutzt wird. Auch diese beherbergt einen eigenen Scheduler sowie eine Lade-Einheit, wichtiger sind jedoch die beiden MMX genannten Integer-Pipelines sowie die beiden FMAC-Pipelines.

Die FMAC-Pipelines bieten dabei AVX-Unterstützung. AMD vermag es, diese Befehlserweiterungen sogar einen Funken besser als das AVX von Intel, das zu Beginn des Jahres eingeführt wurde, zu implementieren. Bei AMD können die beiden FMAC-Pipelines wahlweise jeweils 128 Bit breite Operanden oder zusammen einen 256 Bit breiten Operanden verarbeiten und dabei den „Fused Multiply Add“-Befehl (FMA) nutzen. Der Vorteil einer FMA-Instruktion gegenüber einer herkömmlichen „Multiply Add“-Instruktion ist, dass bei einer FMA erst am Ende der kompletten Berechnung (a*x + y) das Ergebnis gerundet wird, bei einer Multiply-Add-Instruktion hingegen bereits nach der Multiplikation und dann noch einmal nach der Addition. Außerdem werden zwei einzelne Rechenschritte auf einmal erledigt – ohne FMA sind zwei Befehle nötig, die darüber hinaus eine geringere Genauigkeit bieten. Deshalb wird die FMA-Methodik im wissenschaftlichen Bereich bevorzugt, in dem Server-CPUs zum Einsatz kommen – genau dort soll „Bulldozer“ damit punkten.

Am Ende steht noch ein sehr großer L2-Cache bereit, der für das gesamte Modul zur Verfügung steht. Dieser ist gegenüber der Vorgängergeneration deutlich angewachsen, waren bei dieser doch pro Kern lediglich 512 KByte angesetzt. Jetzt sind es für ein Modul mit zwei Integer-Kernen satte 2 MByte.

Zusammengefasst lassen sich diese Informationen mit einer Folie erklären, die Hiroshige Goto für die japanische Seite PC Watch veröffentlicht hat:

Die schematische Darstellung vereinfacht die Ansicht natürlich etwas, in der Serienfertigung sehen das Modul und die darin vorhandenen Elemente wie folgt aus: