»Artemis« zu gut für Konkurrenz?
ARM Cortex-A73 toppt High-End-CPUs
Fortsetzung des Artikels von Teil 1
µOps zusammengeführt – x86 lässt grüßen
Wie eingangs erwähnt, enthält der Cortex-A73 nur noch zwei Befehlsdecoder (diese können neben ARMv8- auch ARMv7- und Thumb-Instruktionen verarbeiten), gefolgt von der bei Out-of-Order-Architekturen notwendigen Registerumbenennungsstufe, die einen Flaschenhals darstellt, da sie auf einen Durchsatz von zwei μOps/Taktzyklus limitiert ist (Bild 4).
Um diesem Problem Herr zu werden, hat ARM zum einen die Anzahl der in µOPs gesplitteten Instruktionen reduziert und zum anderen die sogenannte μOp-Zusammenführung eingeführt, die es bei x86-Prozessoren schon lange gibt. Dabei werden gewisse µOps zu einem µOp zusammengefasst und bis zu den Ausführungseinheiten als ein Eintrag z. B. im Reorder-Puffer geführt. Um es zu ermöglichen, die Befehle in ein bis zwei Taktzyklen zu decodieren, war laut ARM die Einführung von separaten Ausführungseinheiten für Laden und Speichern unabdingbar.
Ein wesentlicher Unterschied zu Cortex‘ A15, A57 und A72 ist die Nutzung eines physikalischen Registersatzes. Die ersten drei genannten arbeiten mit Architektur-Registersätzen, die dynamisch auf die physikalischen Register abgebildet werden müssen. Der physikalische Registersatz ermöglichte beim A73 Vereinfachungen bei der Registerumbenennungsstufe für höhere Rechenleistung bei geringerer Leistungsaufnahme. Wie beim A17 wird auch ein zumindest theoretisch unbegrenztes Out-of-Order-Ausführungsfenster ermöglicht (praktisch gibt es Limitierungen). ARM nennt diese Veränderung einen »signifikaten philisophischen Wechsel beim Ansatz einer Out-of-Order-Mikroarchitektur«.
Ein verbesserter Algorithmus soll dazu für eine Optimierung bei den Ausführungswarteschlangen bzw. bei der Verteilung der Instruktionen in diese sorgen. Der Arbiter, welcher die Reihenfolge der Abarbeitung bestimmt, kann diese auf Basis von bestimmten Ereignissen on-the-fly verändern. Als Beispiel sei das Speichern eines Datenstroms genannt. Wird ein solcher erkannt, werden alle Speicheroperationen in-Order ausgeführt, damit beim Zugriff auf den Speicher eine vollständige Cache-Zeile geschrieben werden kann.
Im Backend sind die Gleitkomma-/NEON-Vektor-Einheiten gegenüber dem Cortex-A72 funktionell im Wesentlichen gleich geblieben (native 128-bit-Operationen im Gegensatz zum A17, der nur zwei 64-bit-Einheiten hatte, für die 128-bit-Operanden in zwei Teile gesplittet werden müssen), wobei der Flächenbedarf gesenkt werden konnte. Die große Veränderung findet sich, wie oben schon angedeutet, im Integer-Teil: Statt wie beim A72 zwei Basis-ALUs plus eine weitere Multi-Taktzyklus-ALU für komplexe Rechenoperationen, gibt es nur noch zwei ALUs, die zu den Basisoperationen zusätzlich entweder multiplizieren oder dividieren können. Während also beim A72 die beiden Basis-ALUs bei Abarbeitung einer MAC-Operation frei für andere Aufgaben blieben, müssen beim A73 parallel beide ALUs ran. Diese auf den ersten Blick nachteilige Veränderung hat aber auch Vorteile: Durch die Parallelisierung wird z. B. die Sättigungsarithmetik beschleunigt. Die ALU für Multiplikation kann zudem Taktzyklen einsparen, wenn bei einer 64×64-bit-Multiplikation die jeweils oberen 32 bit der 64-bit-Operanden Null sind.
Die Revolution: Wechsel der Cache-Architektur
Alles bislang Ausgeführte ist wichtig, aber längst nicht so wichtig wie ein effizientes Speichersubsystem. Hier spielen natürlich die beiden Dual-Issue-Lade-/Speicher-Einheiten eine Rolle, aber noch mehr der Wechsel des Daten-Cache-Typs. Der A72 arbeitete mit einem PIPT-Cache (Physically indexed, physically tagged), der sowohl für Index als auch Tag physikalische Adressen nutzt. Er ist einfach und vermeidet Probleme durch das sogenannte Aliasing (dazu gleich mehr), er ist aber langsam, da die physikalische Adresse aufgelöst werden muss (was einen TLB-Miss und Zugriff auf den Hauptspeicher bedeuten kann), bevor die Adresse im Cache aufgelöst werden kann.
Jobangebote+ passend zum Thema
Statt den PIPT nutzt der A73 einen 64 KB großen VIPT-Datencache (Virtually indexed, physically tagged) bei dem für den Index eine virtuelle Adresse genutzt wird (Bild 5). Der Vorteil gegenüber dem PIPT ist die geringere Latenzzeit, da die Cache-Zeile parallel mit der TLB-Übersetzung aufgelöst werden kann. Das Tag kann natürlich immer noch nicht verglichen werden, bevor die physikalische Adresse verfügbar ist. Ein mögliches Problem ist Aliasing, was bedeutet, dass mehrere virtuelle Adressen auf dieselbe physikalische Adresse zeigen können. Der A73 stellt in Hardware sicher, dass alle Updates auf dieser physikalischen Adresse in-Order ausgeführt werden, indem sich zu jedem Zeitpunkt nur eine Kopie der physikalischen Adresse im Cache befindet. Die Verdoppelung der Cachegröße von 32 auf 64 KB soll laut ARM einen Geschwindigkeitszuwachs von 4 Prozent bringen. Während der Cache hardwareseitig, wie schon ertwähnt, 4-fach-assoziativ ausgeführt ist, wird er von der Software als 8-fach-assoziativer 32 KB großer oder 16-fach-assoziativer 64 KB großer PIPT-Cache gesehen.
Neben den bekannten L1- und L2-Stride-basierenden Prefetchern hat ARM beim A73 einen weiteren Prefetcher eingebaut, der auf die Verarbeitung von komplexen Datenmustern spezialisiert ist. Damit konnte laut ARM der Datendurchsatz beim Streamen von Datenströmen nahe an die theoretisch verfügbare Bandbreite angehoben werden. Last, but not least wurde auch der Haupt-TLB (Übersetzungspuffer, Translation Lookaside Buffer) verbessert, da man bei den A73-Vorgängern bei größeren Datenstrukturen Leistungseinbußen detektieren musste. Indem dem TLB beim A73 eigene Prefetcher zur Verfügung stehen, wurde dieses Problem gelöst. Geändert wurde vermutlich auch die Cache-Ersetzungsstrategie. Während der A17 für alle Caches eine einfache pseudo-zufällige Strategie nutzt, verwendet der A73 vermutlich einen Pseudo-am-längsten-nicht-verwendet-Algorithmus (PLRU, Pseudo-least-recently-used, es wird diejenige Seite ausgelagert, deren letzte Referenzierung zeitlich am längsten zurückliegt). PLRU hat typischerweise eine etwas schlechtere Miss-Rate, dafür kürzere Latenzzeiten und geringeren Energiebedarf als LRU. Die Tabelle fasst die wesentlichen Unterschiede zwischen den Modellen Cortex-A17, -A72 und -A73 zusammen.
| Cortex-A17 | Cortex-A72 | Cortex-A73 | |
|---|---|---|---|
| Befehlssatz | ARMv7-A | ARMv8-A | ARMv8-A |
| Pipeline-Stufen | 11 | 15 | 11/12 |
| L1-Cache Befehle | 32 – 64 KB, 4-Wege-assoziativ | 48 KB, 3-Wege-assoziativ | 64 KB, 4-Wege-assoziativ |
| L1-Cache Daten | 32 KB, 4-Wege-assoziativ | 32 KB, 2-Wege-assoziativ | 32 – 64 KB, 4-Wege-assoziativ |
| ECC L1-Daten-Cache/L2 | Nein/Ja | Ja/Ja | Nein/Ja |
| Speicherschnittstelle | 2 x 64 bit | 128 bit Laden + 128 bit Speichern | 2 x 128 bit |
| L2-Chache | 256 KB – 8 MB | 512 KB – 4 MB | 256 KB – 8 MB |
| Cache-Hierarchie | Nicht inklusiv, nicht exklusiv | Inklusiv | Nicht inklusiv, nicht exklusiv |
| Befehlscoder | 2 | 3 | 2 |
| ALUs | 2 | 3 | 2 |
| Max. Taktfrequenz (MHz)* | N/A | 2,75 GHz | 2,5 GHz |
| Leistungsaufnahme* | N/A | 1,1 W | 0,75 W |
| Rechenleistung/MHz vs. Cortex-A9* | 1,6 | 2,5 | 2,8 |
| Siliziumfläche* | N/A | 1,55 mm² | 1,2 mm² |
Tabelle: Alle Angaben gelten für eine Fertigung in TSMCs 16-nm-FinFet+-Prozess. N/A: Nicht verfügbar. *) Schätzung DESIGN&ELEKTRONIK
- ARM Cortex-A73 toppt High-End-CPUs
- µOps zusammengeführt – x86 lässt grüßen
- Zusammenfassung
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
TechCon 2017
ARMs Entwicklerkonferenz im Zeichen der Security
Neue CPU-Architektur von ARM
DynamIQ ersetzt big.LITTLE
