UMA vs. NUMA bei AMDs Threadripper

[stei.f]

Hallo in die Runde. Ich spiele mit dem Gedanken mit einen 1950x zu zulegen. Daher verfolge ich die Reviews und Newsschnipsel mit grossen Interesse.

Nur eine Sache stösst mir auf (Warum ich mich nach jahrelangen stillen mitlesen, einen Account angelegt hab), das ist die NUMA / UMA Sache.

Ich schreib mal mein Verständnis zum Thema. Am besten am Beispiel von Threadripper (So ich wie mir das Denke. Ich hab leider keine Techpapers gewälzt zu genau der AMD Architektur).

Grundsatz Problem:
Jeder Threadripper DIE hängt an jeweils 2 Speicherkontrollern (von 4 insgesammt). Also sagen wir mal DIE A hängt am 1 + 2 und DIE B am 3 + 4. Wenn wir die Sache simple anschauen, kann A nicht auf Memory von 3+4 zugreifen. Das wäre natürlich Blödsinn. Also was wird gemacht in dem Fall, DIE A bittet DIE B stellvertretend den Memory Block zu laden und über den Interconnect (Infinity Fabric ?) in den Cache vom DIE A zu übertragen. Das bedingt natürlich höhere Latenzen.

Das erklärt mir warum Memory Access auf unterschiedliche Bereiche unterschiedlich lang dauert. -> NonUnifiedMemoryAccess == NUMA

OK wie funktioniert UMA:
Meines Wissens nach wird der Memory gestriped. In welchen Blockgrößen ist vermutlich Herstellerspezifisch. Also erklärend gesagt, DIE A fordert 10 Blöcke Speicher an, bekommt er 5 lokal (mit direktem Zugriff) und 5 remote (die ein anderes DIE stellvertretend laden muss). Das führt dazu das gemittelt die Zugriffszeiten so in der Mitte raus kommen. Im Detail bedeutet das aber dass er ständig zwischen schnell und langsam wechselt (Wenn man sich ein serielles lesen vorstellt).


So jetzt lese ich aber Sachen wie:

https://www.3dcenter.org/artikel/launch-analyse-amd-ryzen-threadripper/launch-analyse-amd-ryzen-threadripper-seite-2 Zitat:
Bei letzteren ergibt sich natürlich die Chance, das mittel- und langfristig eher zugunsten des defaultmäßigen UMA-Modus optimiert wird, und daher unter Spielen die Performancegewinne von NUMA mit der Zeit sinken.
[Ich möchte dem Author nicht ans Bein pinkeln. Ich mag 3dcenter.]

Das ist doch meiner Meinung nach falsch rum gedacht. Wenn man optimiert dann Richtung NUMA. Sprich die HW stellt dem OS Informationen zur Verfügung welcher Speicher eine affinity zu welchen Core(thread)/logischen Prozessor hat. Jetzt ist es am Anwendungsentwickler diese Infos aus dem OS zu quetschen und seine Threads auf den logischen Prozessor zu tackern (thread affinity) um nur lokalen Speicher zu verwenden. Oder anders, wenn die Anwendung Berechnungen im Speicherbereich ZZ hat, den Thread auf dem Prozessor auszuführen der diesen Speicher (ZZ) lokal hat.

Das jenes total kompliziert ist und dem ganzen Thread Skalierungsproblem noch den Hut aufsetzt, ist mir klar. Aber UMA ist aus meiner Sicht eine Gehilfe für Programmierer welche sich nicht mit dem Thema auseinander setzen wollen (und der Vendor versucht den Worst-Case zu verhindern).

Auch vergleiche zu Prozessoren die kein NUMA haben hinken meist. Diese Prozessoren arbeiten nicht im gleichen UMA Mode wie ein Prozessor der NUMA unterliegt. Es ist genau anders herum, ein Prozessor der alles lokal hat ist gleich wie ein NUMA DIE welches auf lokalen Speicher zugreift.

Hier kommen die Themen in den Desktop an denen sich Serveradmins schon seid geraumer Zeit die Zähne abkauen. Da ist das Thema auf jeden Fall Prominent, siehe z.B. Saphana.

Also kann sein das ich total auf dem Holzweg bin, aber dann klärt mich bitte auf. Auch ist die Darstellung vom Threadripper CPU simplifiziert. Die Diskussion ist eröffnet.

ps.: Ich find es toll das AMD das NUMA exposed und nicht jedem UMA vorschreibt.

[ottoman]

Interessant finde ich in dem Zusammenhang auch den Test von PC Perspective, wo Blender zusammen mit einem Spiel lief. Da gibt es große Unterschiede zwischen UMA/NUMA. Allerdings hätte man auch zusätzlich testen können, welche Auswirkungen das Setzen der Affinity/Priority der jeweiligen Prozesse hat. Hier ist der Link: https://www.pcper.com/reviews/Processors/AMD-Ryzen-Threadripper-1950X-and-1920X-Review/Gaming-Performance-and-Mega-tasking (unter dem Punkt "Mega-Tasking Testing")

Ich frage mich auch, inwiefern einzelne Programme sich um NUMA kümmern müssen oder ob das nicht eher die Aufgabe des Thread Scheduler und Memory Management des Betriebssystems ist.

[basix]

Soweit mir bekannt, müssen das die Anwendung von sich aus unterstützen. Deswegen gibt es auch spezielle Server-Anwendungen. Es könnte aber sein, dass das Betriebssystem als Zwischenlayer fungiert. Das heisst, dass die Anwendung ein UMA System sieht, das OS dann auf der HW im NUMA Mode arbeitet und somit Latenzunterschiede verschleiert. Dies ist aber sicher nicht einhergehend mit der besten Performance.

Hier noch ein interessanter Artikel dazu über EPYC und IF, UMA, NUMA sowie der Aufschlüsselung der NUMA-Node Latenzen:
https://www.servethehome.com/amd-epyc-infinity-fabric-latency-ddr4-2400-v-2666-a-snapshot/

[konkretor]

schau mal in die aktuelle CT da hat Andreas Stiller einiges dazu geschrieben und auch die Systeme gebencht

[stei.f]

Ich frage mich auch, inwiefern einzelne Programme sich um NUMA kümmern müssen oder ob das nicht eher die Aufgabe des Thread Scheduler und Memory Management des Betriebssystems ist.
Die Antwort ist schwierig. Das Betriebssystem kann das mit dem Thread Scheduler abfangen, WENN die Anwendung in einem Prozessen läuft und der Prozess-Memory die Größe der NumaBereiche nicht überschreitet. Also wenn man in "Einheit" Prozess denkt, scheint das Lösbar.

Problem ist, hat man mehrere Threads teilen sich die Threads den Speicherbereich. (Im Gegensatz zu Prozessen, welche exklusiven Speicher haben)
Lokaler Speicher < System Gesamtspeicher.

Wäre das OS jetzt knallhart, dann würde es alle Threads eines Prozesses auf einem Numa-Node mit Memory Limit fahren. Hab ich mehr Threads als Physik auf dem Numa-Node, würden die restlichen schlafen.
Andererseits hättest du dann auch ein künstliches Bandbreitenlimit, weil du ja nur 2 Kanäle benutzt.

Das OS müsste entscheiden, willst du Bandbreite, oder Latency. Wieviel Memory wirst du brauchen. Wieviel Threads willst du spawnen. Und wenns richtig Kacke läuft, läuft das Programm in Memory Fragmentation rein und damit langsam in den anderen Numa-Node.

Da wird wohl jedes OS sein eigenes Süppchen kochen oder gleich der Anwendung den schwarzen Peter zuschieben. Ich bin mir nicht mal sicher ob Windows Numa in der API drin hat.

[(del)]

Es ist nett das AMD einem die Wahl gibt welchen Modus man laufen haben will.
Aber das umzusetzen ist zu aufwändig. Wenn man wechseln könnte ohne einen Neustart wäre das toll.
Ich wechsel den Modus z.b gar nicht,lasse es einfach auf default egal ob ich was spiele oder rendere.
Es ist einfach zu aufwändig jedesmal den Rechner neu zu starten.
Daher ist das mit NUMA/UMA eher von theoretischer Natur.

[stei.f]

Ich merk gerade das ich das aus meiner Programmiererwarte verfasst hab (die tolllen neuen Möglichkeiten...und so). Klar für den Anwender ist das alles aufwändig und unnötig kompliziert. Ich würde meinen der default müsste NUMA sein. Das bedingt natürlich das mindestens das OS passt (und mindestens UMA emuliert wenn nötig).

Hier sehe ich wieder die großen Engines im Vorteil (UE4,...). Die hätten die Mittel das Potential (welches hinter UMA [in NUMA]) liegt zu heben. Nur im UMA Mode hat die Anwendung keine Chance.

[Opprobrium]

Es gibt einem halt die Möglichkeit, wenn man ein klar definiertes Anwendungsfeld hat von dem man wenig bis gar nicht abweicht, den Rechner noch etwas zu optimieren.

Die Unterschiede sind ja gering genug, dass sich ein Neustart eigentlich nicht lohnt. Trotzdem ist es schön, dass es die Möglichkeit gibt für sagen wir mal 2-3% Performance Gewinn in 99% der Fälle im verbleibenden 1% auf 2-3% Performance zu verzichten. Durchschnittlich kommen da trotzdem noch 2-3% Gesamtperformancegewinn hinzu :up:

[ottoman]

Im Durchschnitt sind es wenige Prozent, das stimmt. Aber das ist eben nur der Durchschnitt und die Reviews zeigen, dass einzelne Anwendungen bzw. Szenarien große Unterschiede zeigen können. Also muss es im Endeffekt jeder selbst testen. Aber immerhin hat man überhaupt die Möglichkeit, damit zu spielen.

Ich plane in den nächsten Monaten den Kauf des 16C Threadripper. Haupteinsatzgebiet sind rechenintensive VMs und manchmal Games, das dann aber möglichst gleichzeitig. Nach den ersten Infos würde ich NUMA einstellen. Aber ich befürchte jetzt schon, dass ich erstmal alles testen muss, vor allem wenn man die Anwendungen selbst bzw. automatisch auf bestimmte CPU Threads pinnt.

[Leonidas]

So jetzt lese ich aber Sachen wie:

https://www.3dcenter.org/artikel/launch-analyse-amd-ryzen-threadripper/launch-analyse-amd-ryzen-threadripper-seite-2 Zitat:
Bei letzteren ergibt sich natürlich die Chance, das mittel- und langfristig eher zugunsten des defaultmäßigen UMA-Modus optimiert wird, und daher unter Spielen die Performancegewinne von NUMA mit der Zeit sinken.
[Ich möchte dem Author nicht ans Bein pinkeln. Ich mag 3dcenter.]

Das ist doch meiner Meinung nach falsch rum gedacht. Wenn man optimiert dann Richtung NUMA.


Diese Aussage war gedacht für *Spiele*. Und da wird man darauf optimieren, wie die meisten Spieler ihre Prozessoren betreiben. Da vermutlich keiner TR auf NUMA umstellt, werden die Spielestudios TR wohl auf UMA optimieren.

PS: Wichtiges Thema, daher gut, diesen Thread zu haben. Leider tröpfeln zu UMA/NUMA die Infos gerade erst so herein. Ich hab Stunden gebraucht, um aus den bißchen Material der Launchreviews was sinnvolles zusammenzubringen.

[YfOrU]

Würde ich nicht nur auf Spiele beschränken sondern selbst den Großteil der Workstation Applikationen mit einschließen. NUMA ist im Kontext von Desktop und Workstation (Dual Socket Xeon bzw. TR mit zwei Dies pro Socket) eine Nische und wird es auf absehbare Zeit auch bleiben. Da TR oben drein auch noch als UMA konfigurierbar ist wird kaum jemand Ressourcen investieren. Ausnahmen gibt es natürlich aber das sind in erster Line Anwendungen welche hoch skalierbar sind (und nicht nur für Workstations sondern auch für Server entwickelt werden).

Sinn macht NUMA vor allen wenn beispielsweise exzessiv VMware Workstation/Hyper-V eingesetzt wird.

[Leonidas]

Aus dieser Sicht erwartet sich eventelle NUMA-Optimierungen bei Software, wo man davon ausgeht, das *jeder einzelne Nutzer* sich bewußt für UMA/NUMA entscheiden wird. Dies passiert nur im hochprofessionellen Bereich.

Abseits davon wird man schlicht auf den default optimieren. Und der ist bei TR nun einmal UMA. Spieleentwickler können davon ausgehen, das die Mehrzahl ihrer Kunden (auch diejenigen, die TR einsetzen), nichts derart gravierendes am default ändern werden. Ergo ist UMA die klare Wahl für etwaige Optimierungen.

Und damit kann es am Ende durchaus so sein, das in ein paar Jahren UMA im Spielebereich keinen Performance-Nachteil mehr bedeutet - weil es besser durch Optimierungen bedient wird als NUMA.

[Skysnake]

NUMA gibt es schon lange, aber die Anzahl an Anwendungen, die man NUMA Aware programmiert, aber NICHT auf distributed Memory systemen aka Clustern laufen ist recht gering.

Sobald man MPI mit drin hat, hat sich das NUMA Problem im Allgemeinen erledigt. Reines MPI hat eh kein Problem, und wenn man MPI+X benutzt, dann kann man einfach einen MPI Prozess pro NUMA Domain starten und gut ist.

[stei.f]

Naja, in absoluten Zahlen reden wir hier von Best-Case 85ns zu Worst Case 240ns. Da reden wir von einem Aufschlag von ~280% . Wenn man jetzt annimmt das UMA perfekt die Mitte trifft, sind wir bei einem Latenz speedup von 140% von Perfekt NUMA zu UMA bei (0% cach-hit-rate).

Eigentlich müsste ein Threadripper in UMA gegen einen Ryzen ziemlich verlieren. Tut er aber meines Wissens nicht. Die Magie von caches...

Spiele werden eigentlich alle Cacheoptimiert. Sprich das der running kernel(der Teilcode der Arbeit verrichten soll) in den Cache passt. Zusätzlich werden die Datenzugriffe cachline optimiert (man legt sie lokal zum Problem). Auf den Code-Konferenzen wird ja immer gern erwähnt das ein "echter" Speicherzugriff Heute wie ein Festplattenzugriff Gestern war. Nur je mehr Threads man hat, desto bescheidener wird das Problem (Thema cacheline invalidation).
Ein aktuelles Spiel braucht auf Threadripper vermutlich den zweiten DIE gar nicht, oder nur zu Bandbreitenerhöhung.

[dust]

Ich merk gerade das ich das aus meiner Programmiererwarte verfasst hab (die tolllen neuen Möglichkeiten...und so). Klar für den Anwender ist das alles aufwändig und unnötig kompliziert. Ich würde meinen der default müsste NUMA sein. Das bedingt natürlich das mindestens das OS passt (und mindestens UMA emuliert wenn nötig).

Hier sehe ich wieder die großen Engines im Vorteil (UE4,...). Die hätten die Mittel das Potential (welches hinter UMA [in NUMA]) liegt zu heben. Nur im UMA Mode hat die Anwendung keine Chance.

ich sehs genauso wie du

und es wird beim hersteller des pc entschieden in welchem auslieferungszustand, ob n/uma, eingestellt ist... wer sich seine kiste selber zusammenschraubt wird sich solche einstellungen eh ansehen und selbst entscheiden... zumeist numa sinnvollerweise

ich halt die einschätzung, dass die spieleindustrie uma fahren wird weil das ein default setting sein soll, für grundfalsch... eher umgekehrt... alles auf numa weils vorteile bringt... eben auch weil die meisten irgendwelche frameworks verwenden und die framework hersteller, egal ob inhouse oder extern, sind zumeist potent genug auf numa zu optimieren bzw sowieso beides anbieten, ähnlich ogl und dx bzw unterschiedliche plattformen