HWL News Bot
News
Thread Starter
- Mitglied seit
- 06.03.2017
- Beiträge
- 114.149
... weiterlesen
Dynamic Local Mode beschleunigt Threadripper-Flaggschiffe komfortabel
- Ersteller HWL News Bot
- Erstellt am
... weiterlesen
@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:
https://www.phoronix.com/scan.php?page=article&item=2990wx-linux-windows&num=1
https://www.phoronix.com/scan.php?page=article&item=2990wx-linux-windows&num=1
Jain. Windows weiß wie viel Kerne es gibt, und dass diese RAM haben - wie der einzelne Kern angebunden ist, weiß es nicht einfach so. Man kann natürlich überprüfen ob der CPU ein TR mit 4 Dies ist, und dann den Scheduler erst die direkt angebundenen auslasten lassen. Der Nachteil ist dass man dafür keine allgemeine Regel bauen kann, sondern explizit immer auf diese CPU Modelle prüfen muss - da ist eine Software vom Hersteller gar nicht so verkehrt, da dieser noch besser für die CPU Optimierern kann (Intel Turboboost 3.0 macht das auch so. Da weiß die Software welche die "besten" Cores sind, und lasstet diese zuerst aus damit der Boost höher ausfällt)
Zuletzt bearbeitet:
REDFROG
Enthusiast
Also ist das ähnlich wie CPU Affinity selber setzen oder wie?
- Mitglied seit
- 18.02.2005
- Beiträge
- 5.916
Es klingt zumindest so. Allerdings wird der Nutzen bei Programmen, die alle Cores nutzen, gegen Null gehen.
Arkos
Mr. Freelancer
- Mitglied seit
- 02.11.2004
- Beiträge
- 4.843
...
Kannst mit EasyToolZ per Anwendung konfigurieren. Funktioniert superb. Aber nein, ist nicht dasselbe.
EasyToolz - Das Systemtool
...
Zuletzt bearbeitet:
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.
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.
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.
REDFROG
Enthusiast
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.
Zuletzt bearbeitet:
Arkos
Mr. Freelancer
- Mitglied seit
- 02.11.2004
- Beiträge
- 4.843
- Mitglied seit
- 18.02.2005
- Beiträge
- 5.916
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.
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.
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.
- Mitglied seit
- 18.02.2005
- Beiträge
- 5.916
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.
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.
Also abwarten. AMD hat da noch sehr viel Spielraum, um einen Konter nach dem nächsten auf Intel zu werfen.
- Mitglied seit
- 18.02.2005
- Beiträge
- 5.916
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.