Arm TechDays 2019 Auf in Cloud und Infrastruktur: Das ist Arms Neoverse-Universum

Auf den diesjährigen TechDays von arm in San Jose, Kalifornien, stellten Arms Chefarchitekten die schon lange erwarteten IP-Komponenten unter dem Brand »Neoverse« für das Infrastruktur-Cloud-Universum vor. Neben zwei neuen Neoverse-CPUs stand der Systemlösungs-Ansatz im Vordergrund.

Unter dem Brand Neoverse sollen Produkte von den primären CPUs im Rechenzentrum bis hin zu Edge-Computern und Speichermedien angeboten werden. Bis heute hat sich das IP-Portfolio für den Infrastrukturmarkt nicht wesentlich von der Consumer-IP z.B. für Smartphones  unterschieden. Das neue IP-Portfolio wird nun als "Arm Neoverse" bezeichnet.

Auch wenn die Erfolge speziell in Servern bislang limiert waren, konnte Arm in den letzten Jahren einen bedeutenden Marktanteil bei Infrastruktur-Devices  insgesamt erringen. Dabei handelt es sich um jede Art von Nicht-Endbenutzergerät, wie Netzwerk-Devices, Switches, Basisstationen, Gateways, Router und natürlich auch Server. In diesen Märkten zusammen haben Arms Lizenznehmer bis heute einen Marktanteil von bis zu 28% erreicht. Beispielsweise werden auch Top-of-Rack-Switches aufgelistet. Diejenigen, die softwaredefinierte Netzwerke der aktuellen Generation aufbauen, nutzen in der Regel x86-CPUs.

Wie nicht anders zu erwarten, hat arm bereits viele Partner mit ins Boot geholt, denn ohne eine hinreichende Unterstützung durch das Ecosystem wäre Neoverse ja von Anfang an zum Scheitern verurteilt. Neben Halbleiterherstellern wie Qualcomm, Broadcom oder Marvell sind auf der Cloud-Seite Alibaba, Tencent und Microsoft zu nennen, auf der Plattform-Seite Nokia, ZTE, Ericcson, Huawei und CISCO, und von den Telekommunikationsanbietern Softbank, Vodafone, Orange und Sprint. Auf der Software-Seite haben sich 18 Unternehmen komittet, von OS-Herstellern über Virtualisierung, Sprachen&Bibliotheken bis hin zu Entwicklungstool-Herstellern.  Auch wenn einige Key-Player noch fehlen, konnte arm bis zur Ankündigung doch einige große Namen an Bord holen.

Die Neoverse N1 CPU

Das zweifellos wichtigste Puzzleteil  in dem neuen Neoverse-Universum ist eine neue CPU mit der Bezeichnung N1. Sie erreicht im Benchmark SpecInt2006 in ihrem Zielprozess von 7 nm der tawanischen Foundry TSMC mit dem GCC-Compiler der Version 8 einen Wert von 37 pro Core, in einem 64-Core-Hyperscale-Referenzdesign mit 64 Cores wird ein Wert von 1310 erreicht und das mit einer Server-TDP von nur 105 W.

Ein Vergleich mit den heute in Rechenzentren dominierenden Xeon-CPUs von Intel ist insofern nicht einfach, da SpecInt2006-Zahlen mit GCC-Compiler in der Regel nicht veröffentlicht werden. Was wir gefunden haben, ist eine Angabe zum Xeon 8156 aus der veralteten 14-nm-Skylake-Generation mit 24 Cores/48 Threads, der auf einen SpecInt2006-Wert von ebenfalls auf 37 pro Core kommt. Die Leistungsaufnahme des Xeon 8156 beträgt ohne das bei Intel notwendige ergänzende Chipset 205 W bei einer 24 Core/48 Thread-Konfiguration. In wieweit die zukünftigen Intel-Produkte der 10-nm-Generationen Cannon Lake bzw. Ice Lake die Energieeffizienz des Neoverse N1 erreichen werden können, bleibt abzuwarten.

Vorgestellt wurde der N1 von Mike Filippo, seines Zeichens Fellow und Lead Architekt in Arms Entwicklungszentrum in Austin, Texas. Die Entwicklungszentren für Arm-CPUs befinden sich, wie schon mehrfach erwähnt, neben Austin an Arms Firmenzentrale in Cambridge sowie im wunderschönen Sophia-Antipolis in der Nähe von Nizza, dort wo vor 10 Jahren noch Texas Instruments seine OMAP-Prozessoren designte. Der letzte Consumer-Prozessor von Arm, der Cortex-A76, wurde wie auch der Cortex-A72 in Austin designt.

Die Neoverse-N1-Mikroarchitektur wurde mit Blick auf hohe Leistung und Energieeffizienz entwickelt und beinhaltet viele Elemente, die mit dem Cortex-A76 eingeführt wurden. Allerdings wurde sie folgerichtig für Infrastruktur-Workloads und nicht für Smartphones optimiert. Gegenüber der Cosmos-Generation, also dem Cortex-A72, erreicht der N1 bei Server-Workloads die 2,5fache Rechenleistung bei NGINX (ein Webserver unter BSD-Lizenz, der von 62,7 % der Top 10.000 Websites verwendet wird), die 1.7fache Leistung bei Java-basierten Benchmarks (OpenJDK V 11, was alleine 14 % Steigerung gegenüber JDK8 brachte) und nochmal die 2,5fache Leistung beim Memcached-Cache-Server.

Die N1-Mikroarchitektur im Überblick

Die superskalarer Out-of-Order-CPU kommt mit 4 Befehlsdekodern und 8 Ausführungseinheiten daher und weist insgesamt eine 11-stufige Integer-Pipeline auf (Bild 1). Im Frontend hat Arm eine neue Einheit für die Sprungvorhersage und das Laden von Instruktion (Fetch) gebaut, welche "predict-directed fetch" genannt wird, da die Sprungvorhersage direkt Daten in die Befehlsabruf-Einheit eingespeist. Dies ist ein neuer Ansatz, der einen höheren Datendurchsatz als auch eine geringere Stromaufnahme zur Folge hat.

Die Sprungvorhersage setzt dabei wie auch der Cortex-A76  einen hybriden indirekten Prädiktor ein. Der Prädiktor ist von der Fetch-Einheit entkoppelt und seine wichtigsten Strukturen arbeiten unabhängig vom Rest der CPU. Er wird von 3-stufigen Branch-Target-Caches unterstützt: einem 16 Einträge umfassenden nanoBTB, einem 64 Einträge umfassenden microBTB und einem 6 k Einträge umfassenden Haupt-BTB. Die Trefferquote hinsichtlich richtig prognostizierter Verzweigungen im Programmablauf soll sich gegenüber dem Vorgänger nochmals gesteigert haben.

Die Verzweigungseinheit kann pro Taktzyklus acht 16-bit-Instruktionen verarbeiten, welche in eine Fetch-Warteschlange vor dem Laden eines Befehls münden. Diese Warteschlange umfasst 12 Blöcke. Die Fetch-Einheit selbst arbeitet nur mit halbem Datendurchsatz, also pro Taktzyklus werden maximal vier 16-bit-Instruktionen geladen. Im Falle einer fehlerhaft vorhergesagten Verzweigung kann sie durch diese Architektur vor der restlichen Pipeline verborgen werden, ohne dass die Fetch-Einheit und der Rest der CPU blockiert werden.

Auch wenn der N1 eine 11-stufige Pipeline hat, reduzieren sich die Latenzzeiten auf die einer 9-stufigen Pipeline. Wie ist das möglich?  In kritischen Pfaden können sich die Stufen überlappen wie z.B. zwischen dem zweiten Taktzyklus der Sprungvorhersage und dem ersten Zyklus der Fetch-Operation. Während somit nominell 4 Pipeline-Stufen abgearbeitet werden müssen, beträgt die tatsächliche Latenzzeit dank der Überlappung nur 3 Taktzyklen. Die Dekodier- und Register-Umbenennungsblöcke können 4 Befehle pro Taktzyklus verarbeiten, in der Dekodiereinheit werden 2 Taktzyklen benötigt.

Am Ausgang der Dekodierer finden sich sogenannte Makro-Ops, die im Schnitt laut arm um den Faktor 1,07 größer als die ursprünglichen Befehle sind. Die Register-Umbenennung erfolgt getrennt für Integer/ASIMD/Flag-Operationen in separaten Einheiten, die mit Clock-Gating von der Taktversorgung abgeschnitten werden, wenn sie nicht benötigt werden. Dies führt zu enormen Energieeinsparungen. Benötigt die Dekodierung beim N1 zwei Taktzyklen, wurde die Registerumbenennung gegenüber z.B. den Cortex-A73/A75 von 2 auf 1 Taktzyklus verkürzt. Die Makro-Ops werden mit einem Verhältnis im Schnitt von 1,2 pro Instruktion zu Mikro-Ops erweitert, am Ende der Stufe werden bis zu 8 Mikro-Ops pro Taktzyklus ausgegeben.

Die Commit-Puffer-Größe des N1 beträgt 128 Einträge, wobei der Puffer in zwei Strukturen für die Befehlsverwaltung und Registerrückgewinnung aufgeteilt ist – arm nennt es „hybrides Commit-System“.

Die Ausführungseinheiten

Der Integer-Teil enthält 6 Warteschlangen und Ausführungseinheiten, konkret zwei Lade/Speichereinheiten mit entkoppelter Adresserzeugung und Datenpfad, eine Pipeline für Verzweigungen, zwei ALUs, die in der Lage sind, einfache arithmetische Operationen durchzuführen, und eine komplexe Pipeline für Multiplikations-, Divisions- und CRC-Operationen. Die drei Integer-Pipelines und die Verzweigungs-Pipeline werden von 16 Einträgen umfassenden Warteschlangen bedient, wogegen die zwei Lade-/Speichereinheiten jeweils von zwei 12 Einträgen umfassenden Warteschlangen gefüttert werden. Alle Warteschlangen umfassen 3 Pipelinestufen, wobei auch hier die erste Stufe sich mit der Registerumbenennung bzw. dem Versand der Mikro-Ops überschneidet. Damit wurde in Summe ein weiterer Taktzyklus gespart, so dass die Gesamtlatenz nur 9 statt 11 Taktzyklen beträgt. Der für Gleitkomma- und 128-bit-Vektoroperationen (ASIMD) zuständige Teil enthält zwei Pipelines, die von zwei 16 Einträgen umfassenden Warteschlangen bedient werden. Beide Vektor-Pipelines können dabei 128-Bit-Daten verarbeiten. U.a. durch die Nutzung von Gleitkommazahlen mit halber Genauigkeit und 8-bit-Skalarprodukt konnte beim Benchmark DeepBench (ein Open-Source-Benchmarking-Tool, das die Leistung von grundlegenden Operationen misst, die bei der Schulung von tiefen neuronalen Netzwerken durchgeführt werden wie z.B. Matrizen-Multiplikationen) der Score gegenüber einem Cortex-A72 um Faktor 4.7 gesteigert werden.

Wie sieht es nun im Backend mit Befehlsdurchsatz und Latenzzeit aus? Auf der Seite der ganzzahligen Operationen reduziert der N1 die Multiplikation und MAC-Operationen auf 2 Taktzyklen. Die viel größeren und wichtigeren Verbesserungen finden sich in den Vektor-Pipelines, die für Gleitkomma- und ASIMD zuständig sind. Bei der Gleitkomma-Arithmetik beträgt die Latenz 2 Taktzyklen und bei MAC-Befehlen 4 Taktzyklen.

Laden und Speichern von Daten

Die Cache-Architektur des N1 wurde Infrastruktur-Workloads optimiert, welche große Datenstrukturen und in der Regel viele Verzweigungen im Code aufweisen. Die beiden Pipelines für das Laden und Speichern von Daten weisen jeweils eine eigene Warteschlange mit 16 Einträgen auf. Der Daten-Cache ist auf 64 KB festgelegt und ist 4-fach assoziativ. Die Latenzzeit beträgt 4 Taktzyklen. Die I-TLBs/D-TLBs mit 48 Einträgen betreiben eine separate Pipeline. Der N1 bekam wie auch der Cortex-A76 einen völlig neu designten Prefetcher mit  4 verschiedenen Prefetching-Engines, die parallel laufen und verschiedene Datenmuster betrachten und Daten in die Caches laden. Der 64 KB große L1-Befehls-Cache ist beim N1 als erste Arm-CPU überhaupt kohärent, um das Aufsetzen/Löschen von virtuellen Maschinen in virtualisierten Umgebungen mit Hypervisorn zu beschleunigen. Er liest bis zu 32 Bytes/Taktzyklus, gleiches gilt für den L1-Daten-Cache in beide Richtungen. Der L1 ist ein Writeback-Cache.

Der 8-fach-assoziative pro Core vorhandene L2-Cache ist in 512 KB oder 1 MB Größe konfigurierbar, die doppelte Größe wie beim Cortex-A76, seine Latenzzeit beträgt beim Lesezugriff zwischen 9 und 11 Taktzyklen. Ein 1280 Einträge umfassender L2-TLB bietet sogenannte Page-Agggregation, bei welcher jeweils vier kleine Speicher-Pages von 4 KB durch die Mikroarchitektur in 16 KB, 16 KB in 64 KB und 64 KB in 256 KB zusammengefasst werden können.

Alle Cores teilen mit etwaigen Hardware-Beschleunigern und I/Os sich unterhalb der L2-Caches einen System-Level-Cache (SLC), der z.B. in einer 64 MB-Konfiguration in 32 Speicherbänken und einer 64-Core-Konfiguration im Schnitt eine Ladezeit der Daten von 22 ns ermöglicht. Angebunden ist er über  CoreLink CMN-600, ein kohärentes Mesh-Netzwerk nach der AMBA-5-CHI-Spezifikation, das bis zu 32 kohärente CHI-Slave-Schnittstellen beinhalten kann.

Die ganze Speicherarchitektur wurde von Arm für geringe Latenzzeiten, hohe Bandbreite und Skalierbarkeit optimiert, insbesondere jedoch für eine extrem hohe Parallelisierung bei den Speicherzugriffen. Am Ende werden 68 In-Flight-Ladeoperationen und 72 In-Flight-Speicheroperationen ermöglicht.

Die Leistungsaufnahme einer N1-CPU beträgt inklusive 512 KB L2-Cache nur 1,0 bzw. 1.8 W (bei 2,6 bzw. 3,1 GHz Taktfrequenz und einer Core-Versorgungsspannung von 0,75 V bzw. 1.0 V. Die Fläche Silizium beträgt in TSMCs 7-nm-Implementierung pro Core und 512 KB bzw. 1 MB L2-Cache nur 1.2 bzw. 1.4 mm2.

Plattform für Infrastruktur-Anwendungen

Um den Anforderungen aus dem Infrastruktur-Bereich zu genügen, reicht eine passende CPU natürlich nicht aus. Vielmehr muss die ganze Plattform passen.

Eine für jeden Core vorhandene Aktivitäten-Überwachungs-Einheit (AMU für Acitvity Monitoring Unit) steuert die Priorisierung der dynamischen Anpassung von Versorgungsspannung und Taktfrequenz (DVFS). Zudem werden Power-Virus-Szenarios aktiv bekämpft. Ein Power-Virus ist ein Computerprogramm, das einen bestimmten Maschinencode ausführt, um die maximale CPU-Leistungsaufnahme zu erreichen. Computerkühlsysteme sind so konzipiert, dass sie die Leistung bis zur thermischen Designleistung (TDP) und nicht bis zur maximalen Leistung ableiten, und ein Power-Virus könnte das System überhitzen lassen, wenn es keine Logik zum Stoppen des Prozessors hat. Der Neoverse N1 setzt Hardware-Throttling ein, um die Betriebsbedingungen in einem Power-Virus-Szenario auf TDP-Level abzusenken. Bei Nicht-Virus-Workloads hat dies vernachlässigbare Auswirkungen. Die Stromversorgung des SoCs muss daher nur auf TDP-Bedingungen, und nicht auf Virus-Bedingungen ausgelegt werden.

Ein weiteres wichtiges Merkmal sind die Armv8.2. Virtual Host Extensions (VHE). Sie erlauben nicht nur eine Skalierung bis zu 64 K Virtuelle Maschinen, sondern vor allen Dingen den unmodifizierten Betrieb eines Host-Betriebssystems in Exeption Level 2 (EL 2). Bild 2 zeigt ein herkömmliches Szenario beim Einsatz eines Typ-2-Hypervisiors wie KVM mit einem Host-OS Linux in EL 1. In EL 2 läuft der sogenannte KVM LowVisor, der Aufrufe sowohl aus den VMs als auch von dem in EL1 befindlichen KVM erhält. Mit Einsatz der VHE ist es möglich, das Host-OS Linux als auch KVM komplett in EL 2 laufen zu lassen (Bild 3), wodurch aus den EL-übergreifenden Aufrufen zwischen KVM und dem LowVisor mit entsprechenden Latenzen einfache Funktionsaufrufe innerhalb eines EL werden. Da sich die EL1/EL2-Übergänge zwischen VMs und Host nicht vermeiden lassen, hat Arm den Overhead minimiert und die MMU für virtualisiertes Nested-Paging optimiert.

Notwendig ist natürlich auch RAS-Unterstützung. Die Armv8.2.-RAS-Architektur bietet nicht nur ECC-Fehlererkennung (2 Fehler) und –korrektur (1 Fehler) mittels Hamming-Codes in allen Caches, sondern lässt das System auch ohne Fehler weiterlaufen, bis die korrupten Daten tatsächlich verwendet werden.

Software-Analyse per Hardware

Eine Weltneuheit im Arm-Universum sind die statistischen-Profiling-Erweiterungen (SPE). Mit ihnen können detaillierte Informationen wie Sprungfehlvorhersage, Cache-Hit/Miss-Rate oder Latenzzeiten beim Lesen von Daten protokolliert werden, um dem Entwickler bei der Optimierung seiner Software zu helfen (Bild 4). Die Informationen werden direkt in den Speicher geschrieben.

Um zu Systemen mit 128 CPUs (oder noch mehr, eine fundamentale Limitierung gibt es nicht) skalieren zu können, nutzt Arm ähnlich wie auch Intel ein Netzwerk aus Doppelkreuzen (Mesh, #), das sehr niedrige Latenzen und eine hohe Bandbreite bietet, während es Prozessorkerne, Caches, die Speichercontroller und die I/O-Komponenten miteinander verbindet. Die kürzeren weil oftmals direkten Wege, die zudem vielfältiger ausfallen und über Kreuzungen jederzeit die Richtung ändern können, eliminieren viele der mit anderen Topologien wie der Ringbus beim Cortex-A72 zu erwartenden Probleme. Jeder Knoten im Netzwerk ist für die Kommunikation im Netzwerk verantwortlich, es gibt keine Sackgassen. Auch hilft es bei der Skalierbarkeit zu noch mehr Prozessorkernen ohne in große Strafzeiten bei der Latenz zu verfallen.

Mit größer werdenden Caches ist das Mesh-Netzwerk ebenfalls überlegen, da schneller über kürzere Wege an die Daten gelangt werden kann, selbst an die, die nicht direkt am Kern anliegen. Dies hilft dabei, unter anderem den System-Level-Cache auch als eigentlich verstreute Lösung über den kompletten Die am Ende als Unified-Lösung ansprechen zu können. Dies wiederum hat weitere Auswirkungen für den Zugriff auf den Speichercontroller und das I/O-Interface, wenn Daten aus diesem zugezogen werden müssen. Der SLC kommt auf eine Bandbreite von mehr als 1 TB/s.

Die erstmals wie oben erwähnt implementierte Kohärenz des Befehls-Caches reduziert gerade bei großen Installationen den Datenverkehr dramatisch, da beim Wiederaufsetzen einer VM aus einem gesicherten Status die Inhalte der Befehls-Caches nicht mehr für ungültig erklärt werden müssen. Hilfreich zur Synchronisation von Multi-Core-Systemen sind die atomaren Befehle, die mit Armv8.1. eingeführt wurden und Cache-Stashing auf Systemebene, um die CPU-Caches vorzuladen, bevor die Daten angefordert werden. Mittels SmartNICs - eine Netzwerkschnittstellenkarte mit eigenem Prozessor, die Verarbeitungsaufgaben auslagert, die die System-CPU normalerweise ausführen würde wie z.B. Ver- und Entschlüsselung, Firewall, TCP/IP und HTTP-Verarbeitung, was sie ideal für hochfrequentierte Webserver geeignet macht – kann eine weitere Skalierung vorgenommen werden.

Auswirkungen auf die Performance

Wie eingangs erwähnt, stieg die Rechenleistung beim http-Server NGINX um Faktor 2.5, was u.a. auf 2x weniger L1-Cache-Misses, 3x weniger TLB-Misses und 7x weniger falsche Sprungvorhersagen zurückzuführen ist. Die 1.7fache Leistung bei Java-basierten Benchmarks ergibt sich u.a. durch eine um Faktor 2.4 schnellere Objekt/Speicherallokation, eine um Faktor 5 schnellere Objekt/Array-Initialisierung und eine um Faktor 1.6 schnellere Copy-Char-Funktion. Die Cache-Misses und Sprungfehlvorhersagen reduzierten sich um Faktor 1.4 und die Anzahl der L2-Zugriffe dank der optimierten Cache-Architektur um Faktor 2.25.

Bei Memcached reduzierte sich die Anzahl der Sprungfehlvorhersagen um Faktor 3, während die Hit-Rate beim L1-Cache um Faktor 2 anstieg.

Arm sieht die Neoverse-N1-CPU in 64-128-Core-Konfigurationen in Hyperscale-Rechenzentren (Energiebudget 150 W oder höher), in 16-64-Core-Konfigurationen im Edge-Computing (Energiebudget 35-105 W) und in 8-32-Core-Konfigurationen im Bereich Netzwerk-Storage-Security (Energiebudget 25-65 W).

Offenlegung: DESIGN&ELEKTRONIK hat auf Einladung von Arm an den TechDays in San Jose teilgenommen, die Reisekosten wurden zur Gänze von Arm bezahlt. Unsere Berichterstattung ist davon nicht beeinflusst und bleibt gewohnt neutral und kritisch. Der Artikel ist, wie alle anderen auf unserem Portal, unabhängig verfasst und unterliegt keinerlei Vorgaben seitens Dritter.