AMD FX-8150 - Bulldozer im ausführlichen Test

Prozessoren | HT4U.net | Seite 9

Das Frontend


Unter dem Frontend einer Prozessor-Architektur fasst man die Befehlshol-Stufe (Instruction Fetch) samt Sprungvorhersage (Branch Prediction) und die Dekodier-Stufe (Decode) zusammen. Traditionell liegt bei x86-Prozessoren in diesem Bereich das größte Optimierungspotential, denn je mehr und je schneller die Befehle zu den Ausführungseinheiten gelangen, desto performanter ist die CPU. Gerade die häufigen Sprünge und die Übersetzung von x86-Befehlen unterschiedlicher Länge in maschinenverständliche MOP-Befehle sind hierbei zu nennen.

Eine gute Sprungvorhersage ist besonders wichtig, denn wird ein Sprung (beispielsweise eine If-Else-Verzweigung in einem Programm) falsch vorhergesagt, werden die falschen Befehle geladen und teilweise ausgeführt. Die Ergebnisse müssen anschließend verworfen und die Pipeline geleert werden, was Rechenleistung und Energie kostet.

Um die Dekodier-Stufe möglichst konstant mit der maximalen Anzahl an Befehlen zu füttern, hat AMD die Befehlshol-Stufe von der Sprungvorhersage entkoppelt. So ist es nun möglich, dass die Sprungvorhersage unabhängig von der Befehlshol-Logik arbeitet und damit schon Sprünge, die "weit" in der Zukunft liegen, vorhersagen kann. Die Sprungvorhersage kann quasi in der Zukunft arbeiten, während der Rest im "Jetzt" arbeitet. Damit können die Latenzen der Sprungvorhersage (also die Zeit, die es braucht um einen Sprung vorherzusagen) besser "versteckt" werden, was der Performance zu gute kommen soll.

Bild: AMD FX-8150 – Bulldozer im ausführlichen Test
AMD Frontend Details


Die Entkopplung von Sprungvorhersage und Befehlshol-Stufe wird über zwei "Vorhersage-Puffer" (Prediction Queues) – je einer pro Thread – erzielt. Dieser füllt die Sprungvorhersage kontinuierlich mit Zeigern auf zukünftig auszuführende Befehle (relative instruction pointers). Die Befehlshollogik verarbeitet dann diese Pointer und holt die zugehörigen Instruktionen entweder aus dem 64 KByte großen L1-Instruktions-Cache (2-fach assoziativ) oder aus einem höher gelegenen Speicher. Maximal können dabei 32 Byte pro Taktzyklus in den Befehlshol-Puffer (Fetch-Queue) geladen werden, was mehr als 4 Instruktionen pro Takt entspricht.

Durch die Vorhersage-Puffer soll es außerdem möglich sein, dass frühzeitig eine Situation erkannt wird, in der benötigte Befehle noch nicht im L1-Instruktions-Cache liegen (L1-Miss). Damit können die entsprechenden Befehle bereits im Voraus in den L1-Instruktions-Cache geladen werden (Prefetching), was die Wahrscheinlichkeit eines L1-Misses reduziert und damit die Performance steigern sollte.

Die Sprungvorhersage selbst will AMD nach eigenen Aussagen stark verbessert haben (d. h. weniger falsche Vorhersagen), wobei man keine Details preisgibt. Einzig die Größe der Speicher für berechnete Sprungziele (Branch Target Buffer oder kurz BTB) nennt man. So gibt es einen L1-BTB mit 512 Einträgen und einen L2-BTB, der 5120 Elemente besitzt. Zusammengefasst sind die BTBs damit größer als bei der Vorgängergeneration, die nur 2048 Einträge besaß.

Bild: AMD FX-8150 – Bulldozer im ausführlichen Test


Weiterhin hat AMD die Translation-Lookaside-Buffer (TLB) vergrößert. Das ist die Einheit, die Verknüpfungen zwischen logischer und physikalischer Adresse enthält. Der L1-ITLB enthält nun 72 Einträge für unterschiedliche Seitengrößen (2*24 für 4K-Seiten und weitere 24 für 2M- oder 1G-Seiten). Beim Phenom II sind es zum Vergleich nur 48 Einträge und es Fehlen die Einträge für 1G-Seiten. Hieran sieht man deutlich, dass bei Bulldozer zwei Threads pro Modul verarbeitet werden können und diese sich die Ressourcen teilen müssen, weshalb nun mehr Ressourcen zur Verfügung stehen. Auch wenn nur ein Thread abgearbeitet wird, dürften die größeren TLBs von Vorteil sein. Der vier-Wege L2-ITLB fasst unverändert 512 Einträge für 4 KByte große Seiten.

Auch die Dekodierstufe hat AMD an die neuen Bedürfnisse angepasst. So stehen nun vier x86-Decoder statt bisher drei zur Verfügung. Insgesamt können damit bis zu vier x86-Befehle gleichzeitig übersetzt und an die Ausführungseinheiten weitergeleitet werden. Die Decoder selbst sind dabei jenen der Vorgängergeneration sehr ähnlich, verstehen aber natürlich die neuen Befehle, die beispielsweise AES und AVX mit sich bringen.

Daneben beherrschen die Decoder nun auch Branch Fusion. Darunter versteht AMD, dass die Decoder erkennen, dass ein bedingter Sprung – beispielsweise erzeugt durch die Anweisung if(a!=b) – vorliegt und kombinieren den MOP-Befehl für den Sprung direkt mit dem MOP-Befehl für die Bedingung. Dies reduziert die Zahl der Maschinenbefehle, was zu einer höheren Performance und besseren Energieeffizienz führen soll.

Durch bei der gemeinsamen Nutzung des L1-Instruktions-Caches, der Befehlshol- und Dekodier-Stufe der beiden Threads, können natürlich auch Probleme auftreten. Eines ist seit einigen Monaten bekannt und führt in der Linux-Welt zu kontroversen Diskussionen: Es kann passieren, dass die beiden Threads in einem Modul die L1-ICache-Einträge des jeweilig anderen Threads invalidieren. Dies ist natürlich kein gewolltes Verhalten und kann zu Performance-Einbußen führen. Wie hoch diese allerdings sind, ist aktuell schwer abzuschätzen. Ebenfalls ungewiss ist, ob und wenn ja in welchem Maße es auf Windows-Betriebssysteme übertragbar ist.


 

Inhalt dieses Testberichtes