Alle Wege führen nach "Rome"
AMD stellt neue EPYC-Prozessoren für Cloud-Anwendungen vor
Fortsetzung des Artikels von Teil 2
Die CPUs in EPYC V2: Eine Analyse von AMDs Zen-2-Mikroarchitektur
Das Design von Zen-2 hat sich im Vergleich zur ersten Generation von Zen deutlich verändert. Zen-2 basiert auf kleinen 8-Core-Chiplets, die bei der 7-nm-Fertigung von TSMC etwa 80 Quadratmillimeter Siliziumfläche in Anspruch nehmen. Auf dem Die gibt es zwei Cluster mit jeweils 4 Cores, den sogenannten „CCX“, welche neben den vier Cores auch einen geteilten L3-Cache beinhalten. Die CPUs skalieren über die Anzahl der Chiplets, eine 16-Core-Variante beinhaltet z.B. zwei Chiplets, eine 24-Core-CPU deren Drei. Maximal werden bei EPYC-Prozessoren acht Chiplets, also 64 Cores, unterstützt.
Die Chiplets werden über die von AMD „Infinity Fabric“ genannte Schaltmatrix mit einem zentralen I/O-Die gekoppelt, der die gesamte Off-Chip-Kommunikation abwickelt. Er beinhaltet nicht nur alle bis zu 128 PCIe-4.0.-Leitungen für den Prozessor sowie Verbindungen zum externen Speicher (8 Kanäle), sondern auch die Infinity Fabric-Verbindungen zu anderen Chiplets in derselben CPUs oder anderen CPUs. Der I/O-Chip wird nicht in 7 nm bei TSMC, sondern in 14 nm bei Globalfoundries gefertigt. Kein Chiplet kann mit einem anderen Chiplet direkt kommunizieren, sondern alle hängen an dem zentralen I/O-Chip. Insgesamt befinden sich in einem Package somit 9 Silizumplättchen (8 Chiplets plus I/O-Chip), während in der 1. EPYC-Generation nur maximal 4 Dies verbaut wurden.
Mit Zen-2 wurde die zweite Generation der Infinity Fabric eingeführt. Diese unterstützt wie gesagt nun auch PCIe 4.0 und damit eine Busbreite von 512 statt wie zuvor nur 256 bit. Auf Grund der hohen Anzahl der Verbindungen speziell bei den EPYC-Prozessoren von den Chiplets zu dem I/O-Chip hat AMD den Wirkungsgrad um 27% verbessern können, was zu einer geringeren Leistungsaufnahme pro übertragenem Bit führt. Die Taktversorgung wurde jetzt vom DRAM-Hauptakt entkoppelt, nachdem sie in Zen und Zen+ mit der DRAM-Frequenz gekoppelt war. Bei Zen-2 kann der Takt dem DRAM-Takt entsprechen oder aber auch nur halb so groß sein.
Da ein Epyc Gen. 2 alle Speicherzugriffe über den I/O-Chip durchführt, ist die NUMA-Komplexität gegenüber der Vorgängergeneration natürlich geringer. Diese hatte zwei Speichercontroller an jedem der vier CCX, so dass die Zugriffe entweder auf dem selben Die, zu einem Nachbar-Die in demselben Package oder in den anderen Sockel erfolgte. Dort war dann die Zieladresse entweder direkt oder einen weiteren Die entfernt, so dass sich insgesamt 8 NUMA-Domänen und 3 NUMA-Distanzen ergaben.
Mit dem neuen Epyc gibt es nur noch zwei NUMA-Domänen und -Distanzen, nämlich wenn der Speicher am lokalen I/O-Die angebunden ist oder eben an dem anderen. Dadurch wird die Latenz zum entfernteren Speicher deutlich kürzer und vor allem vohersagbar. Minimale Latenzunterschiede gibt es noch in Abhängigkeit des Speichercontrollers, an welchen die Speicherzugriffe über die Infinity Fabric weitergeroutet werden.
Mehr Sicherheit für Zen-2
Schon in seiner ersten EPYC-Generation tat AMD vieles für den sicheren Betrieb im Rechenzentrum getan. So kommt ein Secure-Prozessor vom Typ Arm Cortex-A5 im Einsatz, der ein sicheres Betriebssystem/Kernel mit sicherem Off-Chip-Speicher für Firmware und Daten betreibt, u.a. um kryptografische Funktionen für die sichere Schlüsselgenerierung und Schlüsselverwaltung bereitzustellen. Dies beginnt mit sicheren Booten (TPM), beinhaltet aber auch die Verschlüsselung des sicheren Speichers und die sichere verschlüsselte Virtualisierung.
Die Verschlüsselung beginnt auf DRAM-Ebene, wobei eine AES-128-Engine direkt an die MMU angeschlossen ist. Dies wurde entwickelt, um vor physischen Speicherangriffen zu schützen, wobei jede VM und jeder Hypervisor in der Lage ist, einen separaten Schlüssel für ihre Umgebung zu generieren. Das Betriebssystem oder der Hypervisor kann wählen, welche Pages über Page-Tables verschlüsselt werden sollen, und die DMA-Engines können externe Geräte wie Netzwerkspeicher und Grafikkarten für den Zugriff auf verschlüsselte Seiten unterstützen.
Da jede VM oder jeder Container einen eigenen Verschlüsselungscode erhalten kann, werden diese voneinander isoliert. Dies ermöglicht auch, dass unverschlüsselte VMs neben verschlüsselten VMs ausgeführt werden können. Die Schlüssel sind für die VMs selbst transparent und werden vom geschützten Hypervisor verwaltet. Daneben gibt es direkte RAS-Funktionen im Core. Dies alles ist nicht neu und schon von der ersten EPYC- bzw. Zen-Generation bekannt.
Neu ist bei Zen-2 die Implementierung einer vollständigen hardwarebasierten Sicherheitsplattform gegen Seitenkanalangriffe wie das bekannte „Spectre“, obwohl eine große Anzahl der jüngsten Seitenkanal-Angriffe die AMD-Prozessoren gar nicht betrifft, vor allem wegen der Art und Weise, wie AMD seine TLB-Puffer mit zusätzlichen Sicherheitsüberprüfungen verwaltet. Dennoch gibt es auch eine limitierte Anzahl von Problemen, für die auch AMD anfällig war und die mit Zen-2 der Vergangenheit angehören sollen.
Die neue hardwarebasierte Plattform richtet sich gegen Angriffe wie den sogenannten „Speculative Store Bypass“, besser bekannt als Spectre 4. In Verbindung mit dem Betriebssystem oder virtuellen Speichermanagern wie Hypervisors kann diese Hardware derartige Angriffe unterbinden (Bild 1 der Bilderstrecke). Sicherheitslücken wie L1TF (L1 Terminal Fault), Meltdown oder Microarchitectural Data Sampling für Attacken wie Zombieload sollen laut AMD bei allen Zen-basierten Prozessoren ohnehin schon immer nicht funktionieren.
Neue Instruktion für QoS
Wenn eine Cloud-CPU in verschiedene Container oder VMs für verschiedene Kunden aufgeteilt ist, ist die Rechenleistung nicht immer konsistent, da sie auf Grund der Aktivitäten einer anderen VM auf dem System begrenzt werden kann. Beispiele sind die Speicherbandbreite vom Core zum externen Speicher oder zum L3-Cache. Infolge dessen kann die Zeit, in welcher die VM ihren Workload abarbeitet, schwanken. Wenn sich jedoch eine zeitkritische VM auf einem System befindet und eine andere VM ständig Ressourcen akquiriert, könnte die zeitkritische VM in zu hohe Latenzen reinlaufen. Die meisten Cloud-Betreiber informieren den Kunden nicht einmal darüber, mit welchen anderen VMs die eigenen im Wettbewerb um Ressourcen stehen, von einer Performance-Garantie für eine nachhaltige Performance zu jeder Zeit ganz zu schweigen.
An dieser Stelle kommen bei Zen-2 sogenannte QoS (Quality of Service) Anweisungen zum Einsatz. Der Hypervisor kann damit bei mehreren VMs steuern, auf wie viel Speicherbandbreite und Cache jede VM Zugriff hat. Wenn eine zeitkritische VM Zugriff auf z.B. x MB L3 und mindestens xx GB/s Speicherbandbreite benötigt, kann der Hypervisor steuern, dass diese VM immer Zugriff auf diese Ressourcen hat und diese entweder vollständig aus den verfügbaren Ressourcen für andere VMs herausnehmen oder aber deren Anforderungen einschränken, wenn die zeitkritische VM Zugriff benötigt.
Eine weitere neue Anweisung von Zen-2, CLWB, ermöglicht es dem Programm, Daten vom Cache zurück in den nichtflüchtigen Speicher zu übertragen für den Fall, dass das System einen Haltebefehl erhält und Daten verloren gehen könnten. Die zweite Cache-Anweisung, WBNOINVD, dient dazu, vorherzusagen, wann bestimmte Teile des Cache in Zukunft benötigt werden könnten, und diese proaktiv zu bereinigen, um zukünftige Berechnungen zu beschleunigen. Für den Fall, dass die benötigte Cache-Linie nicht bereit ist, wird vor der eigentlichen zeitkritischen Operation ein Flush-Befehl ausgeführt, während die Anweisung noch in vorherigen Stufen der Pipeline bearbeitet wird. Wird sie dann im Backend ausgeführt, geht dies dank des „Pre-Flush“ schneller. Bild 2 der Bilderstrecke fasst diese 3 neuen Anweisungen zusammen.
Jobangebote+ passend zum Thema
AMDs Zen-2-CPU-Mikroarchitektur
Zen-2-Mikroarchitektur im Detail
Ursprünglich sollte sich Zen-2 nur durch einen geschrumpften Fertigungsprozess von 12 auf 7 nm von der verbesserten ersten Generation Zen+ unterscheiden. Dann hat sich AMD jedoch entschieden, auch architektonische Verbesserungen einzubauen, die zu einer IPC-Single-Thread-Erhöhung im Schnitt um 15 % gegenüber der Zen+ - Architektur geführt haben (IPC: Instruktionen pro Taktzyklus). Bei Multi-Thread-Workloads
Schaut man sich die Übersichtsfolien (Bilder 3 und 4 in der Bilderstrecke) an, sieht Zen-2 der ersten Zen-Generation sehr ähnlich. Die wesentlichen Veränderungen sind eine verbesserte Sprungvorhersage (TAGE-Prädiktor), eine Verdoppelung des Micro-Op-Caches, eine Verdoppelung des L3-Cache, eine Verbesserung der Integer-Verarbeitung durch mehr Ressourcen im Backend, eine Verbesserung des Ladens/Speicherns von Daten ebenfalls durch mehr Ressourcen im Backend sowie die Unterstützung von AVX-256.
Das Frontend
Die Änderungen am Cache-System (Bild 5 in der Bilderstrecke) betrifft primär den L1-Befehlscache, der – Sie lesen richtig - auf 32 KB halbiert wurde, seine Assoziativität sich dabei jedoch von 4fach auf 8fach verdoppelt hat, was die Treffer- Rate hoch hält und für eine bessere Taktbarkeit sowie optimierte SMT-Leistung sorgen soll. Vor allem aber schafft der kleinere L1-Cache den Platz auf dem Die, um das Fassungsvermögen des Micro-Op-Cache von 2.048 auf 4.096 Einträge erhöhen zu können. L1-Cache und Micro-Op-Cache liegen auf dem raumbegrenzten 7-nm-Chip nebeneinander. Der riesige Micro-Op-Puffer hilft, die Rechenleistung bei niedriger Leistungsaufnahme zu steigern, weil so Instruktionen nicht erst decodiert, sondern wiederverwendet werden können. Der L1-Daten-Cache und die L2-Caches blieben unverändert, sie arbeiten in einem 4-Wege- bzw. 8-Wege-2-fach-assoziativen Modus.
Im Frontend hat AMD die bekannte Perceptron-basierte Sprungvorhersage verbessert, um Daten in den L1-Instruktionen-Cache zu laden, zusätzlich wurde aber auch eine TAGE-Sprungvorhersage umgesetzt: Das steht für Tagged Geometric History Length und gilt als eine der derzeit fortschrittlichsten Methoden für eine Sprungvorhersage. AMD spricht in Kombination mit den massiv vergrößerten Branch-Target-Buffern (BTBs) für Befehlszweige und Cache-Requests von einer 30 Prozent verringerten Miss-Rate, was maßgeblich für eine hohe CPU-Geschwindigkeit ist. Der L1-BTB hat sich von 256 Einträgen auf 512 verdoppelt, und der L2-BTB hat sich von 4 K Einträgen auf 7,5 K zumindest fast verdoppelt. Der L0-BTB bleibt bei 16 Einträgen.
Die vier komplexen Befehls-Dekoder in Zen-2 (Bild 6 in der Bilderstrecke) bleiben die gleichen wie bei Zen+. Dekodierte Anweisungen werden im Micro-Op-Cache zwischengespeichert und in die Micro-Op-Warteschlange geschickt. AMD hat weiterhin seinen Mikro-Op-Fusionsalgorithmus verbessert. Im Vergleich zu Zen und Zen+ bedeutet dies, dass der Dekoder eine 256-bit-AVX2-SIMD-Anweisung nicht in zwei Mikro-Ops zerlegen muss.
Über die Decoder hinaus können die Micro-Op-Warteschlange und das Dispatching sechs Micro-Ops pro Taktzyklus in die Scheduler einspeisen. Dabei können in den Integer-Scheduler sechs Mikro-Ops pro Taktzyklus eingespeist werden, in den Gleitkomma-Scheduler hingegen nur vier. Da jedoch gleichzeitig Mikro-Ops an beide Scheduler versendet werden können, würde ein Engpass nur dann auftreten, wenn versucht würde, in einem Taktzyklus mehr als 4 Gleitkomma-Mikro-Ops einzuspeisen.
Integer-Verarbeitung und Lade/Speicheroperationen
Die Integer-Scheduler können wie soeben gesagt bis zu sechs Mikro-Ops pro Taktzyklus aufnehmen, welche in die nunmehr 224 Einträge (statt 192 bei Zen+) umfassenden Reorder-Puffer eingespeist werden. Die Integer-Einheit im Backend verfügt statt über 6 nunmehr über 7 Ausführungseinheiten, bestehend aus vier ALUs und drei AGUs (Address Generation Units). Bild 7 in der Bilderstrecke zeigt das Integer-Backend.
Die Scheduler bestehen aus vier ALU-Warteschlangen mit jeweils 16 Einträgen und einer AGU-Warteschlange mit 28 Einträgen, wobei die AGU-Einheit 3 Mikro-Ops pro Taktzyklus in den Registersatz einlesen kann. Die drei AGUs speisen in die Lade-/Speichereinheit ein, die zwei 256-Bit-Ladeoperationen und eine 256-Bit-Schreiboperation pro Taktzyklus unterstützen kann (Bild 8 in der Bilderstrecke). Nicht alle drei AGUs sind gleich: AGU2 kann nur Speicheroperationen abbilden, während AGU0 und AGU1 sowohl Laden als auch Speichern können.
Die Speicherwarteschlange wurde von 44 auf 48 Einträge erhöht, und auch die TLBs für den Daten-Cache wurden erhöht. Die Lade-/Speicherbandbreite pro Core beträgt statt 16 Bytes pro Taktzyklus bei Zen+ nunmehr 32 Bytes pro Taktzyklus bei Zen-2.
Gleitkomma-Verarbeitung und Caches
Die wichtigste Verbesserung für die Gleitkomma-Rechenleistung ist die vollständige AVX2-Unterstützung (Bild 9 in der Bilderstrecke). AMD hat die Breite der Ausführungseinheit von 128 Bit auf 256 Bit erhöht, was AVX2-Berechnungen mit einem Zyklus ermöglicht, anstatt die Berechnung in zwei Anweisungen und zwei Taktzyklen zerlegen zu müssen. Da ja wie soeben beschrieben in einem Taktzyklus nunmehr auch 32 Bytes (=256 Bit) geladen/gespeichert werden können, können die Gleitkomma-Einheiten kontinuierlich mit Daten versorgt werden. Eine weitere wichtige Verbesserung ist die Verringerung der Gleitkomma-Multiplikationslatenzzeit von 4 auf 3 Taktzyklen.
Abgesehen von den schon beschriebenen Veränderungen am L1-Befehls-Cache ist der L1-Daten-Cache ist immer noch 32 KB groß und arbeitet 8-fach-assioziativ, während der L2-Cache immer noch 512 KB groß ist und ebenfalls 8-fach-assioziativ arbeitet (Bild 10 in der Bilderstrecke). Diese beiden Cache-Ebenen sind pro Core privat angelegt, während der der L3-Cache pro CCX angelegt ist und sich mit Zen-2 von 8 MB auf 16 MB verdoppelt hat. Durch die Vergrößerung des L3 hat sich dessen Latenzzeit erhöht. Die Latenz des L1-Caches beträgt unverändert 4 Taktzyklen, die des L2-Befehls-Caches unverändert 12 Taktzyklen aber die Latenzzeit des L3 ist von rund 35 auf rund 40 Taktzyklen gestiegen. Die Latenz des L2-Daten-Caches sank von 8 auf 7 Taktzyklen.
- AMD stellt neue EPYC-Prozessoren für Cloud-Anwendungen vor
- AMDs neue EPYC-Prozessoren der 2. Generation
- Die CPUs in EPYC V2: Eine Analyse von AMDs Zen-2-Mikroarchitektur
- Fazit
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
