Mikroprozessoren Cortex-A75 macht Single-Thread-Apps glücklich

Nach dem großen Erfolg von ARMs Cortex-A73 war das Designziel des Cortex-A75 eine höhere Rechenleistung bei gleichbleibender Leistungsaufnahme. Tatsächlich schafften es ARMs Architekten, rund 20 Prozent mehr Rechenleistung bei gleicher Energieeffizienz herauszuquetschen.

Nach wie vor gibt es in der Multicore-Ära die große Herausforderung, dass die Skalierung von Anwendungen über die verfügbaren CPUs nicht immer wirklich funktioniert. Insbesondere bei „Alt-Code“, der seinerzeit für Single-Core-Architekturen entwickelt wurde, sind die Angaben der Hersteller mehr Wunsch als Wirklichkeit.

Aufgrund der in der letzten Ausgabe vorgestellten DynamIQ-Architektur [1] und einer verbesserten Mikroarchitektur des Cortex-A73 konnte die Integer-Rechenleis-tung für Single-Thread-Anwendungen laut SPECINT2006 um 22 % und die Gleitkomma- und Vektorverarbeitung laut SPECFP2006 sogar um 33 % gesteigert werden.

Dazu kommt ein um 16 % höherer Datendurchsatz zum/vom Speicher (gemessen mit Octane 2.0.) mit DynamIQ. Setzt man allerdings eine identische Energieeffizienz wie beim A73 an, so reduziert sich die Rechenleistungssteigerung auf 20 %, was aber nicht weniger beeindruckend ist.

Das Designziel des unter dem Codenamen »Prometheus« entwickelten Cortex-A75 bestand daher darin, wie beim Vorgänger A73 (Codename »Artemis«), eine hohe und vor allen Dingen durchgängige Rechenleistung auch für Single-Thread-Workloads zur Verfügung zu stellen.

Entwickelt wurde der A75 wie der A73, auf dessen Architektur er aufsetzt, in ARMs CPU-Designcenter im französischen Sophia-Antipolis, das neben dem A73 schon für die 32-bit-Cortex-A12 und -A17 verantwortlich zeichnete. Daneben gibt es noch ein Designteam in ARMs Firmenzentrale in Cambridge, das A5, A7 und A53 konzipierte und eines im texanischen Austin, das für A15, A57 und A72 – die drei größten Energiefresser in der Geschichte der ARM-Cortex-A-Familie - verantwortlich zeichnete.

Schaut man sich Bild 1 an, das links die Pipeline des A73 und rechts die des neuen A75 zeigt, ist ersichtlich, dass es sich um eine ähnliche, vergleichsweise kurze 11-13-stufige Pipeline wie beim A73 handelt. Die erste Stufe zum Laden der Befehle umfasst immer noch vier Stufen, die Dekodierstufe kann die meisten Instruktionen in nur einem Taktzyklus verarbeiten, statt in drei wie beim A72. Lediglich Gleitkomma-µOps durchlaufen eine zusätzliche Dekodierstufe, sodass für diese Befehle die gesamte Pipeline 13 Stufen lang ist.

Zurück zu drei Dekodern 

 Allerdings können die Befehlsdekoder nunmehr erneut, wie schon beim A72, drei statt zwei Instruktionen pro Taktzyklus dekodieren (Bild 2). Das bedeutet, dass statt vier nun sechs µOPS/Taktzyklus an die Befehlswarteschlangen ausgeliefert werden können. Jede Ausführungswarteschlange kann mit zwei µOPs gefüttert werden, womit wir bei einem weiteren großen Unterschied wären:

Jede Ausführungseinheit mit 2 ALUs und 2 AGUs haben nämlich ihre eigene Warteschlange, während sich beim A73 jeweils zwei Einheiten eine Warteschlange geteilt haben. In Summe haben die ALU-Warteschlangen jetzt 24 (2×12) Einträge (1×8 beim A73) und die AGU-Warteschlangen 16 (2×8) Einträge (1×12 beim A73). Bei Verzweigungen gibt es nach wie vor 20 Einträge.

Ergänzend zu Bild 1 muss noch erwähnt werden, dass einfache Verzweigungen die Dispatch/Rename-Stufe umgehen können und damit 2 Taktzyklen einsparen. Da dies aber nur für einfache Verzweigungen gilt, die beispielsweise ohne Zugriff auf Register durchgeführt werden können, ist dieser Pfad in Bild 1 nicht dargestellt.

Angesichts der Tatsache, dass die IPC (Instruktionen pro Taktzyklus) des A75 beim SPECint2006 im Schnitt 1,2 beträgt (es gibt Bereiche mit nur 0,6, aber auch Bereiche mit 1,8) muss man natürlich fragen, was der dritte Dekoder bringen soll. Es gibt Situationen, in denen ein hoher Durchsatz sinnvoll ist, wie nach einer Sprung-Fehlvorhersage, die trotz ausgeklügelter Algorithmen immer noch bei 1000 Befehlen in zwei bis vier Fällen auftritt. In diesen Fällen muss die Pipeline komplett gelöscht und so schnell es geht mit neuen Instruktionen gefüllt werden. Trotz des Nachteils einer unvermeidlichen höheren Leistungsaufnahme musste ARM ein superskalares 3-Wege-Design wählen, um seine IPC-Ziele zu erreichen.

Wie schon der A73 arbeitet der A75 mit einem physikalischem Registersatz zur Speicherung von µOPs, während der A72 mit einem Architektur-Registersatz, der dynamisch auf die physikalischen Register abgebildet werden muss, ausgestattet ist. Auch einen Reorder-Puffer sucht man vergebens.

Beim A75 neu sind einige Optimierungen etwa die Möglichkeit, dass Lade- Speicher-Operationen umgehen.Dadurch wird die generelle Out-of-Order-Ausführung verbessert und Cache-Misses auf dem L2-Cache können besser bewältigt werden.

Desweiteren hat man beim A73 festgestellt, dass bestimmte Befehle, die während der Dekodierung aufgebrochen werden, weil sie während der Umbenennung Zugriff auf den Registersatz benötigen, zuviele Einträge in den Warteschlangen belegen. Beim A75 werden diese daher nach der Umbenennung wieder in einer Instruktion zusammengeführt, um in den Warteschlangen Platz für andere µOPs zu schaffen. 

Dritte Gleitkomma- Pipeline im Backend 

Auf der Gleitkomma-/NEON-Seite gibt es beim A75 wie auch beim A73 keine Dispatch-Stufe. Es können beim A75 drei statt zwei µOPs/Taktzyklus und zwei µOPs pro Warteschlange verarbeitet werden, wobei letztere vier statt drei Stufen umfasst. Die Anzahl der Einträge ist mit acht pro Warteschlange unverändert geblieben, da Untersuchungen mit mehr Einträgen das Ergebnis brachte, dass die Erhöhung der Leistungsaufnahme größer war als der Gewinn an Rechenleistung. Stattdessen wurde eine weitere separate Pipeline für die Speicherung von Daten ergänzt. Die Latenzzeit einer Gleitkomma-MAC-Operation wurde von sechs (A73) auf fünf Taktzyklen reduziert. 

Während der A72 mit einen PIPT-Cache (Physically indexed, physically tagged) arbeitete, der sowohl für Index als auch Tag physikalische Adressen nutzt, hat der A75 wie der A73 einen 64 KB großen VIPT-L1-Datencache (Virtually indexed, physically tagged) bei dem für den Index eine virtuelle Adresse genutzt wird. 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 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 A75 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. Während der Cache hardwareseitig 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. Der L2-Cache läuft in der neuen DynamIQ-Architektur mit voller Core-Frequenz, was die Latenzzeit gegenüber dem A73, bei dem alle CPUs eines Clusters den L2-Cache geteilt haben, um mehr als 50 % reduziert. Beim Laden von Befehlen reduziert sich die Zeit von 20-25 Taktzyklen auf 11 Taktzyklen (10 Taktzyklen für L1-Miss und L2-Treffer) und für das Szenario mit der geringsten denkbaren Latenzzeit von 19 auf 8 Taktzyklen.

Der L2-Cache kann mit 256 oder 512 KB ausgeführt werden, wobei 512 KB gegenüber 256 KB in einem Single-Core-Szenario nur 2 % Geschwindigkeitsgewinn bringt, bei vier Cores in einem Cluster immerhin 4-5 %.

Neben den bekannten L1- und L2-stride-basierenden Prefetchern hat ARM beim A75 einen weiteren Prefetcher eingebaut, der auf die Verarbeitung von komplexen Datenmustern spezialisiert ist. 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/A75 eigene Prefetcher zur Verfügung stehen, wurde dieses Problem gelöst.

Nicht-blockierender TLB 

 Neu beim A75 ist ein nicht-blockierender TLB (beim A73 gab es einen blockierenden TLB). Falls durch einen TLB-Miss ein Gang durch die Page-Tabellen im Hauptspeicher notwendig wird, was durch die zahlreichen Speicherzugriffe sehr zeitaufwendig ist, kann der nicht-blockierende TLB währenddessen weitere Anforderungen für Übersetzungen von virtuellen in physikalische Speicheradressen verarbeiten. Schließlich wurde der Datendurchsatz erhöht, indem die Größe des Store-Puffers (STB) auf 7 jeweils 128 bit große Einträge erhöht wurde.


Da die Sprungvorhersage des A73 sehr gut arbeitet und weitere Verbesserungen nur auf Kosten der Leistungsaufnahme zu realisieren gewesen wären, blieben der Sprungzieladressen-Puffer (BTAC) und der zusätzliche Micro-BTAC mit seinen 64 Einträgen, die zu Geschwindigkeitsgewinnen bei wenigen aber häufig angesprungenen Zieladressen bringen, unverändert. Um die immer noch verbliebenen Fehlvorhersagen möglichst energieeffizient abarbeiten zu können, wurde ein Stack mit Rücksprungadressen für verschachtelte Unterprogramme implementiert. Zusätzlich wurde eine statische Vorhersage implementiert, die als Fallback-Lösung für den Fall dient, dass die Hauptvorhersage eine unzureichende Historie aufweist. Eine weitere Vorhersage für indirekte Verzweigungen wird nur aktiviert, wenn er benötigt wird (dies spart Energie, da indirekte Verzweigungen relativ selten auftreten). Er nutzt einen 2-Wege-BTAC mit 256 Einträgen. 

Piplines im Backend unverändert 

Die beiden Integer-Pipelines des A75 sind gegenüber dem A73 unverändert geblieben. Dies bedeutet, dass beide Basisoperationen wie Additionen und Bit-Verschiebungen parallel ausführen können, aber nur eine kann Multiplikationen und MAC-Operationen ausführen. Die andere beherrscht im Gegenzug die Integer-Division. Dies bedeutet, dass parallel eine MUL/MAC-Operation mit DIV/ADD/Shift ausgeführt werden kann, nicht jedoch beispielsweise MUL und MAC oder DIV und ADD. Fast alle Operationen benötigen ein oder zwei Taktzyklen, die Multiplikation 3 Taktzyklen und die Division vier. Angesichts des dritten Dekoders dachte ARM darüber nach, eine dritte ALU-Pipeline zu implementieren, der Zuwachs an Rechenleistung rechtfertigte jedoch die höhere Leistungsaufnahme nicht, wie Simulationen ergeben haben. 

Die beiden Gleitkomma/NEOEN-Vektor-Pipelines haben, wie in Bild 1 ersichtlich ist, ihre eigene Umbenennungsstufe und einen eigenen 128-bit-Registersatz. Damit können pro Taktzyklus acht 8-bit-Integer, vier 16-bit-Integer-, zwei 32-bit-Integer oder Gleitkomma-Operationen mit einfacher Genauigkeit oder eine 64-bit-Integer- oder Gleitkomma-Operation mit doppelter Gennauigkeit ausgeführt werden. Ein Programmierer kann seine Anwendung somit zwischen Rechenleistung und Genauigkeit ausbalancieren.

Mit der im A75 implementierten Architektur ARMv8.2. wurden auch Gleitkommaoperationen mit halber Genauigkeit, also 16 bit Datengröße, eingeführt (Bild 3). Damit reduziert sich der benötigte Platz in den Caches und im Hauptspeicher, was logischerweise den Datendurchsatz erhöht. Beim A73 und seinen Vorgängern war es zwar auch möglich, Daten im Gleitkommaformat mit halber Genauigkeit zu laden, allerdings mussten diese vor der Verarbeitung intern noch ins Format mit einfacher Genauigkeit umgewandelt werden, was zusätzlichen Overhead und Latenzzeiten generiert hat.

Im Speziellen nutzen viele Algorithmen für neuronale Netzwerke zur Erhöhung der Ausführungsgeschwindigkeit dieses FP16 genannte Datenformat, erst recht, wenn das Training vorbei ist. Um diese Algorithmen weiter zu beschleunigen, wurde mit ARMv8.2. noch eine weitere Instruktion eingeführt, nämlich das INT8-Skalarprodukt, welche diverse herkömmliche Instruktionen zu seiner Berechnung zusammenfasst und damit die Latenzzeiten wesentlich reduziert.

Bei künstlichen Neuronen hat man einen Eingabevektor, einen Gewichtsvektor, eine Aktivierungsfunktion, eine Ausgabefunktion und den Ausgabewert des Neurons. Der Zusammenhang mit realen Neuronen ist folgender: Der Eingabevektor stellt die Werte der Dendriten anderer Neuronen dar und der Gewichtsvektor modelliert die Synapsen. Die Aktivierungsfunktion repräsentiert die Aktivität des Neurons und über die Ausgabefunktion wird schließlich der Wert berechnet, der an nachfolgende Neuronen weitergeleitet wird. Die Gewichte des Gewichtsvektors können so eingestellt sein, dass sie wie die Synapsen hemmend oder verstärkend auf Eingabesignale wirken. Für die Aktivierungsfunktion wird häufig das Skalarprodukt (gewichtete Summe) von Eingabevektor und Gewichtsvektor verwendet, das mit dem INT8-Skalarprodukt des A75 sehr schnell berechnet werden kann. 

Fazit 

Der Cortex-A75 ist absolut betrachtet beileibe kein Energiesparwunder, reizt man ihn komplett aus, nimmt er mehr Energie auf als sein Vorgänger A73, was angesichts der erweiterten Mikroarchitektur allerdings auch nicht überraschend ist. Die Energieeffizienz liegt bei diesem Betriebspunkt unterhalb des A73. Wenn man ihn allerdings auf das Energie-Niveau des A73 heruntertaktet, liefert er im Schnitt – natürlich anwendungsabhängig - immer noch 20 % mehr Rechenleistung, was sehr beeindruckend ist.


ARMs Design-Team in Austin. Texas, wird den von ihm als Letztes designten Cortex-A72 nicht als Basis für den Nachfolger des A75 nehmen können, sondern wohl quasi bei Null anfangen müssen, um den A75 hinsichtlich Rechenleistung und Energieeffizienz weiter zu verbessern. Im internen Wettbewerb zwischen ARMs drei Design-Teams durfte (oder musste?) der französische Ableger – was sehr ungewöhnlich ist – zwei Cortex-A-CPUs direkt nacheinander entwickeln.

Last but not least: Der Abstand in der relativen Rechenleistung/MHz zu Intels Goldmont-CPU aus den Atom-SoCs steigt weiter an. Betrug dieser beim Cortex-A73 bereits 15 % [2], steht mit dem A75 ein Vorteil von rund einem Drittel zu Buche. Wenn nicht zwangsläufig auf x86-Kompatibilität und/oder das Intel-Ecosystem angewiesen ist, wird die Alternative ARM dank des A75 noch attraktiver finden. (fr)

Referenzen


Riemenschneider, F.: DynamIQ ersetzt big.LITTLE. DESIGN&ELEKTRONIK 2017, Ausgabe 7, Seite 34 ff.

Riemenschneider, F.: Intels »Goldmont« macht »Atom« wettbewerbsfähig. DESIGN&ELEKTRONIK 2017, Ausgabe 5, Seite 50 ff.