> > > > Dynamic Local Mode beschleunigt Threadripper-Flaggschiffe komfortabel

Dynamic Local Mode beschleunigt Threadripper-Flaggschiffe komfortabel

Veröffentlicht am: von

threadripper teaserAMD Ryzen Threadripper 2990WX und 2970WX können mit ihren 32 bzw. 24 Kernen eine beeindruckende Rohleistung bieten. Längst nicht jede Anwendung kann davon aber voll profitieren. Ein Grundproblem bleibt, dass je nach Anwendung mal der UMA- und mal der NUMA-Modus für mehr Performance sorgt. Ein neuer Dynamic Local Mode soll nun für mehr Komfort ein ein Leistungsplus sorgen.

Bereits erwähnt haben wir den Dynamic Local Mode mit der Ankündigung der Verfügbarkeit des Ryzen Threadripper 2920X und 2970WX mit 12 und 24 Kernen zum 29. Oktober. Nun wollen wir aber noch einmal genauer auf den neuen Software-Modus eingehen.

AMD hat diesen Modus selbst in einem ausführlichen Blogeintrag näher vorgestellt. Der Dynamic Local Mode ist eine Softwarelösung, die den anspruchsvollsten Anwendung automatisch die CPU-Kerne zuweist, die direkt an den Arbeitsspeicher angebunden sind. Genutzt werden kann dieser Modus aber ausschließlich auf Threadripper-Modellen mit vier Dies, also auf dem Ryzen Threadripper 2990WX und dem (erst Ende Oktober verfügbaren) Ryzen Threadripper 2970WX. 

Wie sinnvoll eine solche Lösung sein kann, macht ein Blick auf den Aufbau dieser Prozessoren deutlich. Nur zwei der vier Dies haben eine direkte Anbindung zu den Speicherkanälen. Gerade bei latenzabhängigen Anwendung sinkt die Leistung, wenn sie nicht auf den Kernen mit direkter Speicheranbindung ausgeführt werden. Der NUMA-Modus (Non-Uniform Memory Access, auch Local Mode) weist zwar jedem Die einen festen Speicherbereich zu und senkt so die durchschnittlichen Latenzen, gleichzeitig sinkt aber auch die Speicherbandbreite gegenüber dem UMA-Modus (Uniform Memory Access, auch Distributed Mode). Welche Anwendung nun von welchem Modus mehr profitiert, muss der Nutzer selbst herausfinden. Bisher ist auch der Wechsel zwischen beiden Modi mit einem Neustart verbunden und wenig praktikabel.  

Weil AMD schon den NUMA-Modus als Local Mode bezeichnet, ist der neue Dynamic Local Mode praktisch eine neue und fortschrittlichere Spielart des NUMA-Betriebs. Der Wechsel wird damit im laufenden Betrieb möglich. Umgesetzt wird der Dynamic Local Mode durch einen Windows 10-Hintergrunddienst. Dieser Dienst misst, wieviel CPU-Zeit jeder Thread benötigt. Die Threads werden dementsprechend in eine Rangfolge eingeordnet. Anschließend werden den Dies mit direkter Speicheranbindung automatisch die am meisten fordernden Threads zugewiesen. Die Kontrolle und Zuweisung ist ein dauernder Prozess.

Um den Dynamic Local Mode zu stoppen, kann entweder der Dienst selbst gestoppt oder einfach über Ryzen Master deaktiviert werden. Verfügbar werden soll der neue Modus am 29. Oktober. Dann will AMD eine neue Version von Ryzen Master ausliefern, die auf Systemen mit Ryzen Threadripper 2990WX oder 2970WX automatisch den Dynamic Local Mode aktiviert. In Zukunft soll dieser Modus auch Teil des AMD Chipsatz-Treibers werden und auch ohne die Ryzen Master-Software genutzt werden können. 

AMD hat selbst Tests durchgeführt, die dem Dynamic Local Mode einen teils deutlichen Performancezuwachs bescheinigen. Es wird zwar nicht ausdrücklich darauf hingewiesen, die Messungen dürften aber im Vergleich zum bisher werkseitig aktiven UMA-Modus durchgeführt worden sein. Die Anwendungen profitieren sehr unterschiedlich vom Dynamic Local Mode. In Battlefield 1 wird mit 47 Prozent der deutlichste Zuwachs erreicht (DirectX 12/Ultra, 136 FPS vs. 200 FPS). Bei den anderen einbezogenen Spielen/Benchmarks variiert der Zuwachs zwischen 10 und 21 Prozent. AMD weist auch darauf hin, dass nicht jede Anwendung vom neuen Modus profitieren wird.

Social Links

Ihre Bewertung

Ø Bewertungen: 5

Tags

Kommentare (15)

#6
customavatars/avatar19663_1.gif
Registriert seit: 18.02.2005

Computer Schach Freak
Beiträge: 3536
Zitat REDFROG;26565437
Also ist das ähnlich wie CPU Affinity selber setzen oder wie?

Es klingt zumindest so. Allerdings wird der Nutzen bei Programmen, die alle Cores nutzen, gegen Null gehen.
#7
Registriert seit: 02.11.2004

Mr. Freelancer
Beiträge: 4518
Zitat REDFROG;26565437
Also ist das ähnlich wie CPU Affinity selber setzen oder wie?


...

Kannst mit EasyToolZ per Anwendung konfigurieren. Funktioniert superb. Aber nein, ist nicht dasselbe.

[ATTACH=CONFIG]446226[/ATTACH]

EasyToolz - Das Systemtool

...
#8
customavatars/avatar44491_1.gif
Registriert seit: 08.08.2006
SN
Moderator
Beiträge: 34159
Zitat Kullberg;26565807
Es klingt zumindest so. Allerdings wird der Nutzen bei Programmen, die alle Cores nutzen, gegen Null gehen.


Naja, wenn du Last erzeugst ohne groß Memory Zugriffe respektive primär Cache gepuffert, dann bringt das dort wahrscheinlich nix. Betreibst du aber Mischumgebungen, wo du vllt neben deinem Renderjob noch ein Spielchen laufen hast, könnte das schon funktionieren.

Die Manuelle Pinmethode funktioniert aber eh immer. Und die nutzt man wahrscheinlich auch wenn man so ne CPU nutzt.

Zitat NasaGTR;26564983
Mal eine Frage aus Unwissenheit: Warum gibt es hierfür eine extra Software, müsste sowas nicht tief im Windows Kerner eingebaut werden? CPU Zuweisung ist doch etwas sehr hardwarenahes oder?


Der Prozessor "gaukelt" dem OS vor, es wäre ein 4x NUMA Design, bringt aber nur an 2x der 4x Nodes eigenen Speicher mit.
Das wohl größte Problem von Windows ist das Threadgeschubse.

Wenn MS da aber nix hardcoded, wird es schwierig bei diesen Bedingungen das via Scheduler zu lösen. Was genau das Ding hier bei AMD macht, ist ja nicht ganz klar, oder?
Möglicherweise pinnt es auch nur die Threads - oder der Spaß geht noch tiefer. Dieses Turbo 3.0 Ding von Intel da pinnt ja auch Threads - teils mit negativen Auswirkungen, weil eben dann auf 1-4 Threads fix gepinnt wird und damit der Takt zwar steigt für den Core, die Leistung absolut aber sinkt, weil bisschen MT doch mehr gebracht hat...

Was noch dazu kommt ist die Tatsache, dass die "Leute" meist versuchen das Design abseits der Grenzen und Limitierungen mit der Brechstange für andere Einsatzzwecke zu missbrauchen. Normalerweise kommen da nur die wenigsten auf die Idee - aber im Clientbereich haben die Leute davon schlicht keinen Plan (meist). Ein 4x NUMA Design hat halt 4x NUMA Nodes. Und wer da ein Single non NUMA aware Task mit 64 Threads drauf fahren will, weil das Ding nunmal 64 Threads in Summe kann - bricht mit den Grenzen des Designs -> und muss sich dann mMn auch nicht wundern, wenns scheiße läuft.

Leider sind aber die Zahlen die man da ließt pures Marketing. Denn nicht der non NUMA aware Software-Wert ist 100%, sondern normalerweise sollte eine NUMA aware Software/Bench bei Nutzung eines Multi-NUMA Designs die Basis sein. Und ausgehend von dieser Basis kommt die Umsetzung mit dem Dienst dann an so und so viel Prozent ran... AMD suggeriert aber hier x% Performancegewinn, obwohl nichts gewonnen wird - es wird ja deswegen nicht schneller. Die mit bisschen Abstand schnellste Lösung bleibt ne NUMA aware Software.

Zitat Redphil;26565014
@NasaGTR: Afaik ist das ein Windows-Problem, das sich wohl unter Linux so gar nicht erst stellt. Deswegen wohl auch der Performancevorsprung von TR II unter Linux:
A Look At The Windows 10 vs. Linux Performance On AMD Threadripper 2990WX - Phoronix


Ganz so einfach ist das aber auch nicht...
Auch Linux unterliegt den Restriktionen des Hardware Designs. Schau dir mal im Vergleich dazu die Werte bspw. der 2700X Linux/Win10 Vergleiche an. Da sind auch paar Benches bei, die laufen absolut ohne jegliche NUMA Themen auf der Linux Umsetzung einfach weit schneller (sogar in ähnlichem Maßstab zu den TR Werten) -> Blender ist so ein Fall wo das seit Jahren bekannt ist. "Minion" aus dem Test ist auch so ein Fall.

Ist am Ende schwer das passgenau zu vergleichen, da funkt einfach ne Menge mit rein und kleinste Details können große Wirkung haben. Um so schwerer ist am Ende da ein Urteil zu fällen. Denn oft ist das dann eben nicht auf eine Pauschale eingrenzbar. OpenMP lässt sich bspw. als einer der Gründe benennen. Je nachdem, gerade bei bezahlmich oder Drittanbieter Software ist meist der Spaß für Windows precompiled fix und fertig, während du die Linux Version nicht selten völlig frei compilieren kannst - mit allen guten wie schlechten Optimierungen.
#9
customavatars/avatar150117_1.gif
Registriert seit: 12.02.2011
Baden Württemberg
Kapitän zur See
Beiträge: 3227
Zitat Arkos;26566563
...

Kannst mit EasyToolZ per Anwendung konfigurieren. Funktioniert superb. Aber nein, ist nicht dasselbe.

[ATTACH=CONFIG]446226[/ATTACH]

EasyToolz - Das Systemtool

...


Danke, ich nutze für meinen 1950X das "Process Lasso"
Aber ich schaue mir easytoolz auch mal an!

edit.. ok ist leider bei weitem nicht so gut und umfangreich wie Process Lasso..mit Abstand. ^^

---

Aber auch mit diesem Dynamic Local Mode werden mir die 4-aktive-Dies-Threadripper nicht gerade viel attraktiver.
#10
Registriert seit: 02.11.2004

Mr. Freelancer
Beiträge: 4518
Zitat REDFROG;26566744
Danke, ich nutze für meinen 1950X das "Process Lasso"
Aber ich schaue mir easytoolz auch mal an!

edit.. ok ist leider bei weitem nicht so gut und umfangreich wie Process Lasso..mit Abstand. ^^




Jo, auch grad gesehen, ... shame on me :D

...
#11
customavatars/avatar19663_1.gif
Registriert seit: 18.02.2005

Computer Schach Freak
Beiträge: 3536
Nochwas zur Begriffsbestimmung:
Tasks / Processes kann man von anderen Programmen aus pinnen (=Affinities setzen). Der Befehl in C++ dafür ist SetProcessAffinityMask. Den kann man leicht in eigene Tools einbauen, was ich in diversen privaten Tools auch gemacht habe. Threads kann nur das Programm, das sie gestartet hat, der Thread selbst und der Kernel bestimmten Cores zuweisen. Der Befehl in C++ dafür ist SetThreadAffinityMask - ein handle zu fremden Threads, der dafür nötig wäre, wird vom System bei Windows nicht 'rausgerückt. Deshalb muss das Programm selbst das können - was bei den besseren Schach Programmen auch der Fall ist.
#12
customavatars/avatar6158_1.gif
Registriert seit: 13.06.2003
RheinMain
Admiral
Beiträge: 9868
AMDs Optimierungen sind noch lange nicht am Ende. Natürlich hat das Design seine Ecken und Kanten, die gerade zur Zeit von TR1 noch einen erheblichen Rückstand bedeutet haben. Aber so langsam wird das. Und so wie AMD Kerne nachballert, spätestens in 7nm, wird auch die Industrie nicht drumrum kommen, ihre Software zu optimieren.
#13
customavatars/avatar19663_1.gif
Registriert seit: 18.02.2005

Computer Schach Freak
Beiträge: 3536
Ich wage zu bezweifeln, dass AMD wesentliche Verbesserungen für Threadripper in petto hat. Das Konzept beim TR2 2990WX (ich hab einen) ist und bleibt problematisch. Ein Konzept wie das von Intel (28 Cores auf einem Die) ist wesentlich unproblematischer. Ob der Aufpreis dafür OK ist, muss jeder für sich selbst entscheiden.
#14
customavatars/avatar6158_1.gif
Registriert seit: 13.06.2003
RheinMain
Admiral
Beiträge: 9868
Das Problem bei TR2 ist eher das QuadChannel-Interface. AMD hätte einen X499 bringen müssen, der den TR2 auf allen acht Speicherkanälen freischaltet - und zusätzlich läuft der TR2 auf den alten X399-Brettern mit angezogener Handbremse.

Also abwarten. AMD hat da noch sehr viel Spielraum, um einen Konter nach dem nächsten auf Intel zu werfen.
#15
customavatars/avatar19663_1.gif
Registriert seit: 18.02.2005

Computer Schach Freak
Beiträge: 3536
So einfach ist das nicht. Zwar wären 8 Speicherkanäle schon besser, aber es ist immernoch ne CPU mit 4 NUMA Nodes. Ich hab nen Rechner mit 4x Xeon E5-4650, also auch 4 NUMA Nodes, allerdings 16 Speicherkanäle. Software, die NUMA nicht unterstützt, läuft darauf grauenhaft lahm.
Um Kommentare schreiben zu können, musst Du eingeloggt sein!

Das könnte Sie auch interessieren: