„Kernentwurf ist nur ein Teil der Gleichung.“ Der Satz steht in der Analyse zu Nvidias Vera, und er trifft den Punkt. Die Olympus-Kerne des Server-Chips sind mit großen Out-of-Order-Strukturen ausgestattet und darauf ausgelegt, pro Takt viel Arbeit zu erledigen. Das ist der sichtbare Teil. Der unsichtbare ist die Frage, wie diese Kerne mit Daten versorgt werden. Dort entscheidet sich, ob ein Chip mit hoher Kernzahl seine Rechenleistung im Alltag abrufen kann.
Wer sich länger mit Prozessoren beschäftigt, kennt diese Verschiebung des Interesses. Irgendwann ist der Kern nicht mehr der spannende Teil, sondern der Weg zwischen Kern und Speicher. Am einfachsten lässt sich das mit einem Straßennetz vergleichen. Die Bandbreite ist die Zahl der Spuren, die Latenz die Fahrzeit vom Absender bis zum Empfänger, und die Caches sind Lagerhallen an den großen Kreuzungen. Ein noch so leistungsfähiges Fahrzeug bringt nichts, wenn es auf der Zubringerstraße im Stau steht. Je mehr Fahrzeuge gleichzeitig unterwegs sind, desto wichtiger wird, dass die Kreuzungen nicht zum Nadelöhr werden. Diese Rolle übernimmt bei Vera die Scalable Coherency Fabric.
Die Scalable Coherency Fabric als Verkehrsnetz des Chips
Die SCF ist die zweite Generation von Nvidias chipweitem Interconnect und übernimmt dieselbe Aufgabe wie das Mesh bei Intel oder der CMN bei Arm: Sie verbindet Kerne, Cache und Off-Chip-Anbindung zu einem kohärenten Ganzen. Wie schon bei Grace, dem Vorgänger, dürfte Vera auf eine Mesh-Topologie setzen, also auf ein Raster aus Knotenpunkten, zwischen denen Daten kurze Wege haben. Ein Mesh ist kein Zaubermittel, aber es skaliert ordentlich, solange die Knotenanzahl im Rahmen bleibt und die Wege nicht zu lang werden.
Die Analyse beschreibt mehrere Knotentypen. Die Coherency Switch Nodes, kurz CSN, beherbergen Kerne und Cache und ähneln funktional den Mesh-Stops bei Intel. Ein Unterschied fällt auf: Nvidia legt auf jeden dieser Knoten gleich ein Paar von Kernen, nicht nur einen. Das hält die Zahl der Knoten klein, was die Wege im Raster kurz und den Entwurf überschaubarer macht. Der Autor nennt als Vergleich Amperes Altra Max, wo jeder kohärente Request-Knoten eine Arm DynamIQ Shared Unit mit zwei Neoverse-N1-Kernen trägt. Dass zwei Hersteller unabhängig voneinander zur selben Bündelung greifen, sagt einiges darüber, wie sehr die Knotenzahl zum Problem wird, wenn man sie ungebremst wachsen lässt.
Darunter liegen die Memory Switch Nodes, die von der Fabric zu den LPDDR5X-Controllern brücken, sowie die Bridge Switch Nodes für PCIe-Controller und die Verbindung zwischen zwei Sockets. Das ist sauber getrennt: Rechnen, Speicher, Peripherie hängen jeweils an eigenen Anschlusspunkten im Netz, statt sich eine gemeinsame Schnittstelle zu teilen. Für die Frage, wie sich Last auf den Chip verteilt, ist das relevant, weil der Speicherverkehr nicht zwangsläufig denselben Weg nehmen muss wie der Verkehr zu den PCIe-Geräten.
1024 Bit LPDDR5X: woher die Bandbreite kommt
Der auffälligste Unterschied zu Grace liegt beim Speicherinterface. Vera fährt eine 1024 Bit breite Anbindung an LPDDR5X-9600, über die Memory Switch Nodes kommen bis zu 1,228 TB/s Bandbreite zusammen. Das ist kein gradueller Sprung mehr, sondern eine andere Liga. Über die 88 PCIe-Lanes kommen noch einmal bis zu 665,5 GB/s für Peripherie dazu, und der Cross-Socket-Link NVLink C2C bringt theoretisch 1,8 TB/s mit. Ein einzelner Chip bringt damit Bandbreiten, für die andere Server-Plattformen mehrere Sockets brauchen.
Grace hatte den Servermarkt mit LPDDR5X aufgemischt, blieb bei der DRAM-Leistung aber hinter den Erwartungen zurück. Die Latenz lag bei über 200 Nanosekunden, und die Bandbreite war in absoluten Zahlen in Ordnung, fiel gegenüber zeitgenössischen DDR5-Servern jedoch etwas ab. Vera dreht das Verhältnis um: Die Bandbreite liegt jetzt vor der Konkurrenz, und die Latenz ist auf ein Niveau gerutscht, das mit DDR5-Aufbauten vergleichbar ist. Dazu kommt ein Detail aus dem Rechenzentrumsalltag, das leicht übersehen wird. Vera verwendet SOCAMM2-Module, der Speicher ist damit im Feld tauschbar und potenziell aufrüstbar. Bei Grace war der Speicher fest verlötet, ein defekter Chip bedeutete damals ein Problem, das sich nicht mit einem Modultausch lösen ließ.
Latenz unter Last: warum Vera nicht in den Stau läuft
Der interessante Teil der Messungen betrifft nicht die Spitzenbandbreite, sondern das Verhalten unter Druck. Ein Thread, der per Pointer Chasing durch den Speicher läuft, sieht dem Autor zufolge auch dann nicht mehr als 200 Nanosekunden Latenz, wenn andere Threads den Chip an seine Bandbreitengrenze treiben. Andere Server-Plattformen zeigen an dieser Stelle den bekannten Hockey-Stick-Verlauf: Die Latenz bleibt lange flach und schießt nach oben, sobald die Speichercontroller an ihr Limit kommen.
Für den Betrieb ist das der Unterschied zwischen einem Server, der unter Last gleichmäßig antwortet, und einem, der unter Last unberechenbar wird. Das Phänomen kennt man aus virtualisierten Umgebungen als Noisy-Neighbor-Effekt: Ein Mandant zieht Speicherbandbreite, und alle anderen spüren es, ohne selbst etwas falsch gemacht zu haben. Bleibt die Latenz auch bei hoher Auslastung stabil, lässt sich dieses Übersprechen deutlich besser kontrollieren. Die Analyse geht sogar so weit, Vera einen Vorteil beim Skalieren in DRAM-gebundenen Workloads zuzuschreiben, selbst wenn der Chip weniger Kerne hat als die Konkurrenz. Um die Größenordnung einzuordnen, multipliziert der Autor die Werte eines einzelnen Xeon-6-Dies mit drei.
Der L3-Cache als Puffer vor dem Speicher
Selbst ein Speicherinterface dieser Breite kann nicht jeden Zugriff eines Programms direkt bedienen. Deshalb setzt Vera wie andere Hochleistungs-CPUs auf große Caches, um die Speichermauer abzufedern. Der L3-Cache fasst 164 MB und wird von allen Kernen gemeinsam genutzt, steht aber in keinem inklusiven Verhältnis zu den kernprivaten L2-Caches. Was im L2 liegt, muss also nicht zwingend auch im L3 liegen. Wenn keine Daten doppelt in den L2-Caches gehalten werden, kommt Vera so auf bis zu 340 MB effektiv nutzbare Last-Level-Cache-Kapazität. Für Adressen, die von vielen Kernen gelesen werden, kann der L3 eine einzige Kopie vorhalten und damit Kapazität sparen.
Beim Durchsatz wird es interessanter. Die Lese-Bandbreite des L3 liegt bei etwa 3,35 TB/s, umgelegt auf alle Kerne sind das rund 33,1 GB/s pro Kern. Ein einzelner Kern erreicht ohne Konkurrenz durch die Nachbarn 88,5 GB/s. In absoluten Zahlen bleibt es ordentlich, und die 2 MB L2 pro Kern dürften einen guten Teil des Bedarfs abfangen, bevor überhaupt ein Zugriff auf den L3 nötig wird. Der Autor vergleicht das mit AMDs Ansatz, der auf über den Chip verteilte Kapazität setzt und dabei sehr hohe L3-Bandbreite liefert. Genoa-X gibt einem einzelnen Kern rund 90 GB/s und fällt bei Volllast nur auf etwa 85 GB/s ab, weil der Chip in Oktacore-Cluster aufgeteilt ist und jede L3-Instanz nur acht Kerne bedienen muss.
Die 1248 MB L2 plus L3, die Genoa-X insgesamt bietet, können bei multithreaded Anwendungen mit weitgehend thread-privaten Daten im Vorteil sein, ebenso beim parallelen Betrieb vieler verschiedener Jobs. Teuer wird es, wenn Threads viele Daten teilen, weil dieselben Daten dann in mehreren L3-Instanzen liegen und Kapazität verschwenden. Dazu kommt eine strukturelle Grenze: Ein einzelner Thread kann bei Genoa-X nur in seine 96-MB-Instanz allozieren, während Vera einem Thread theoretisch den gesamten L3 von 164 MB zugänglich macht.
Zwei Sockets über NVLink C2C: viel Bandbreite, wenig Tempo
NVLink C2C verbindet zwei Sockets als Punkt-zu-Punkt-Strecke, und ein Dual-Socket-System bildet zwei NUMA-Knoten, je einen pro Socket samt direkt angeschlossenem Speicher. Zugriffe auf den Speicher des anderen Knotens kosten 309,27 Nanosekunden Lade-zu-Nutzungs-Latenz, also 177,41 Nanosekunden mehr als ein lokaler Zugriff. Kurios ist, wie dieser Wert zustande kommt: Er verlangt einige Dutzend GB/s Verkehr auf dem Link. Lässt man den Pointer-Chasing-Test isoliert laufen, misst der Autor über 370 Nanosekunden. Der Link wechselt also erst bei ausreichender Nachfrage in einen höheren Leistungszustand, wenn sich Anfragen vor ihm stauen.
Beim Durchsatz liefert NVLink C2C viel. Lesen erreicht knapp über 587 GB/s, ein Read-Modify-Write-Muster mit Datenfluss in beide Richtungen kommt auf 780 GB/s. Damit hat Vera mehr Cross-Socket-Bandbreite als jede andere Dual-Socket-Konfiguration, die dem Autor bekannt ist, und mehr als die meisten Server überhaupt zu ihrem direkt angeschlossenen Speicher aufbieten. Bei der Latenz fällt der Link dagegen zurück. AMD gibt für Genoa-X 222,7 Nanosekunden bei Cross-Socket-Zugriffen an, und die straffe Kontrolle, die Vera über lokale DRAM-Zugriffe hat, gilt hier nicht. Unter hoher Last steigt die Latenz, bei 780 GB/s im Read-Modify-Write-Muster auf ebenfalls 780 Nanosekunden.
Ein Interconnect muss dafür sorgen, dass Schreibvorgänge global sichtbar werden, selbst wenn die Daten nur im privaten Cache eines Kerns liegen. Ein Test, der einen Wert per atomarer Operation zwischen zwei Threads hin und her schickt, misst auf Kernpaaren im selben Socket im Schnitt 148,5 Nanosekunden, mit einer Spanne von 87,5 bis 199,3 Nanosekunden je nach Paar und Eigentümer der Cacheline. SMT-Geschwister liegen unter 10 Nanosekunden, ein Kern kann Kohärenz zwischen seinen eigenen Threads also ohne den langsameren Weg über den Interconnect herstellen. Zwischen Sockets sind es dagegen rund 660 Nanosekunden, was hoch ist; Genoa-X kommt auf etwa 209, und Graviton 4 liegt laut Analyse noch besser. Innerhalb eines Sockets ist Veras Latenz immerhin gleichmäßig, aber durchgängig höher als bei Grace und im Schnitt auch höher als bei Graviton 4 und Genoa-X.
Was die SPEC-Zahlen über Kernzahl und Durchsatz sagen
Die CPU-Rate-Suite von SPEC lässt sich nutzen, um Durchsatz zu messen, indem man mehrere Kopien jeder Arbeitslast gleichzeitig laufen lässt. Mit einer Kopie pro Hardware-Thread schlägt Vera Graviton 5 im Knoten-zu-Knoten-Vergleich ohne Mühe, und auch ein Zen-5-Modell mit geringerer Kernzahl, das kurioserweise als ein einziger NUMA-Knoten über beide Sockets konfiguriert war, bleibt dahinter. Auf Socket-Ebene dreht sich das Bild, dort fällt Vera hinter Graviton 5 zurück. Der Vergleich hinkt ein wenig, weil Graviton 5 den gesamten Socket nicht als einen NUMA-Knoten darstellen kann, zeigt aber einen grundsätzlichen Zielkonflikt: Ein dicht gepackter Entwurf mit schwächeren Kernen liefert oft höheren Gesamtdurchsatz, sofern genug Arbeit vorhanden ist, um all diese Kerne zu beschäftigen. SMT hilft Vera, die Lücke zu verkleinern, gegen mehr als die doppelte Kernzahl reicht es trotzdem nicht.
Bei Workloads mit hohem Bandbreitenbedarf kehrt sich der Vorteil wieder um. Das Beispiel 749.fotonik3d aus SPEC CPU gilt als sehr DRAM-lastig, selbst auf einem Ryzen 7 9800X3D mit einer einzigen Kopie. Für die socketweiten Läufe auf Vera und Graviton 5 wurden keine Performance-Monitoring-Daten erhoben, aber die Annahme liegt nahe, dass beide Chips hier an der Speicherbandbreite hängen. Wer viele Kopien laufen lässt, hat pro Kopie weniger Cache zur Verfügung, und damit steigt der Druck auf den Speicher.
Für die Praxis heißt das: Vera ist kein Chip, der über Kernzahl gewinnt, sondern über die Fähigkeit, viele Kerne gleichzeitig mit Daten zu versorgen, ohne dass die Latenz einbricht. In DRAM-gebundenen Workloads und in Umgebungen mit vielen Mietern auf einer Maschine ist das ein handfester Vorteil. In Workloads, die von roher Thread-Parallelität und gleichmäßig niedriger Latenz über Socket-Grenzen hinweg leben, bleibt die Rechnung gemischt, weil genau dort die 660 Nanosekunden zwischen zwei Sockets wehtun. Veras Systemarchitektur ist vor allem eine Wette darauf, dass Bandbreite pro Kern und Latenzstabilität unter Last langfristig mehr zählen als die letzte Zeile im Datenblatt.
Quelle: chipsandcheese.com
