Threadripper 3990X: Performance skaliert unter Linux besser als unter Windows

Jetzt ist Ihre Meinung gefragt zu Threadripper 3990X: Performance skaliert unter Linux besser als unter Windows

Dank seiner 64 Kerne und 128 Threads lädt der Threadripper 3990X dazu ein, die Performanceskalierung unter Linux mit der unter Windows zu vergleichen. Dabei zeigt sich wieder einmal, dass der Linux-Kernel besser mit vielen Threads zurechtkommt als das Betriebssystem aus dem Hause Microsoft.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

Zurück zum Artikel: Threadripper 3990X: Performance skaliert unter Linux besser als unter Windows

Ein Grund warum Windows so schlecht mit den Kernen skaliert (besonders ab 64 Threads): Sobald mehr als 64 Threads vorhanden sind, splittet Windows 10 Home/Pro die Threads und tut so, als hätte man mehrere Sockel. Das beeinflusst die Performance negativ.
Link: The Windows and Multithreading Problem (A Must Read) - The 64 Core Threadripper 3990X CPU Review: In The Midst Of Chaos, AMD Seeks Opportunity

Bei Linux hat man das Problem nicht. Daher skaliert das Ganze gerade bei einer hohen Kernanzahl besser.

Der Test zeigt das es nicht an Windows an sich liegt sonder daran wie die Entwickler sich entschieden haben die APis zu verwenden oder zu missbrauchen. Sieht man schön daran das bei manchen Programmen die Skalierung unter Windows sogar besser ausfällt. Was sagt uns das? Wenn Programmierer glauben sie sind schlauer als der Optimizer oder das betriebssystem dann fliegen sie meistens heftig auf die Schnauze.
Microsoft had den Scheduler für Threadripper schon mehrmals angepasst weil die CPU sich anders verhält als man erwarten würde und auch anders als sie dem OS meldet.
Der Windows-Scheduler geht eben von einer anderen Ausgangslage aus. Das Problem sind Prozesse mit einer hohen Anzahl An threads auf einem System mit mehreren NUMA-Knoten die nicht die Thread-Affinität selbst managen. Alles (auch die APIs) gehen davon aus das der Prozess entweder nicht viele Threads spawned die auf unterschiedlichen Nodes laufen, oder wenn er viele spawned das er die zuordnung zu den nodes selbst übernimmt da ja der prozess selbst am besten weis was er macht.
Im ersten Fall wird das gemacht was für die meisten Anwendungen auch Sinnvoll ist: es wird versucht die Threads im selben Node zu halten. Dumm nur wenn es dann >64 Threads auf 4 Nodes verteilt gibt die ständig alle auf den sleben node verschoben werden - und dadurch dann andere Threads des selben Prozesses auf andere Nodes.

Unter Linux läuft der Scheduler deutlich anders - was in manchen Situationen besser, in anderen Schlechter ausfällt.
Und wunder oh wunder - Prozesse die mit die Threadzuweisung selbst übernehmen können deutlich besser laufen.
(Und das ganze ist noch deutlich komplizierter als meine Vereinfachung hier)

Was mach ich jetzt bloß mit dem 3990X ?!

Welche Games nutzen die 64 Kerne unter Linux voll aus ?

Und warum kann Microsoft W10 nicht dahingehend Updaten , schließlich habe ich dafür ca. 140 Euro ausgegeben !

Äh ja hauptsache 64 Kerne , da wird sich schon noch ein Argument dafür finden

@Casurin

Doch, das Problem liegt bei Windows. Die haben irgendwo einmal die 64 Kerne (eigentlich Threads) statisch festgelegt und anstatt das zu ändern dann die "Processor Groups" drangepfuscht. Heißt ich kann als Entwickler meine Anwendung gar nicht über mehr als 64 Threads ohne extra Aufwand skalieren.
Processor Groups - Win32 apps | Microsoft Docs

NUMA hat damit nichts zu tun, das ist für den jeweils zugehörigen Speicher relevant. Der 3990X hat übrigens nur 2 NUMA Nodes.

plusminus schrieb:

Was mach ich jetzt bloß mit dem 3990X ?!

Welche Games nutzen die 64 Kerne unter Linux voll aus ?

Und warum kann Microsoft W10 nicht dahingehend Updaten , schließlich habe ich dafür ca. 140 Euro ausgegeben !

Äh ja hauptsache 64 Kerne , da wird sich schon noch ein Argument dafür finden

Zum Vergrößern anklicken....

Was mach ich jetzt bloß mit dem Thread?

Welchen Bullshit schreibe ich denn jetzt mal? Dabei habe ich doch so ein dringendes Mitteilungsbedürfnis, das mein Aufmerksamkeitsdefizit verursacht...

Äh ja, hauptsache ich schreibe jetzt einfach, wie immer, irgendeinen Unsinn, der niemanden interessiert, aber da wird sich schon jemand finden, der mir etwas Aufmerksamkeit widmet.

Tolle CPU nur halt absoluter Unsinn und eher was können wir machen.
Der Nutzen ist aber bei der CPU mal richtig eingeschränkt, was will man den mit 256Gb Ram
auf einem 128 Thread System.

Wenn man die Threads brauchen könnte hat man mit dem Ram limit zu kämpfen
768 Gb hätte das minimum sein müssen auf dem, aber 256 Gb ist eben gerade das minmum wo
man wirklich so eine Rechenpower brauchen kann.


AMD hat bei der CPU nur daran gedacht ihren eignen CPUs nicht zu schaden.
Und so ist es eher eine Machbarkeitsstudie wie wirklicher nutzen.

jadiger schrieb:

AMD hat bei der CPU nur daran gedacht ihren eignen CPUs nicht zu schaden.
Und so ist es eher eine Machbarkeitsstudie wie wirklicher nutzen.

Zum Vergrößern anklicken....

Wir sind einfach nicht die Zielgruppe, deal with it. Ich kann damit gut leben.

sterreich schrieb:

Heißt ich kann als Entwickler meine Anwendung gar nicht über mehr als 64 Threads ohne extra Aufwand skalieren.
Processor Groups - Win32 apps | Microsoft Docs

Zum Vergrößern anklicken....

Bitte lies dir den Link den du da gepostest hast erst mal durch. Wenn du etwas nicht verstehst dann bitte frag nach bevor du hier so vielBullshit von dir gibst.

Casurin schrieb:

Bitte lies dir den Link den du da gepostest hast erst mal durch. Wenn du etwas nicht verstehst dann bitte frag nach bevor du hier so vielBullshit von dir gibst.

Zum Vergrößern anklicken....

Aus dem Windows Artikel

Support for systems that have more than 64 logical processors is based on the concept of a processor group, which is a static set of up to 64 logical processors that is treated as a single scheduling entity.

Zum Vergrößern anklicken....

von anandtech:

When the system is in this mode, it becomes very tricky for most software to operate properly. When a program is launched, it will be pushed into one of the processor groups based on load – if one group is busy, the program will be spawned in the other. When the program is running inside the group, unless it is processor group aware, then it can only access other threads in the same group. This means that if a multi-threaded program can use 128 threads, if it isn’t built with processor groups in mind, then it might only spawn with access to 64.

Zum Vergrößern anklicken....

The Windows and Multithreading Problem (A Must Read) - The 64 Core Threadripper 3990X CPU Review: In The Midst Of Chaos, AMD Seeks Opportunity
Wenn du mich also über meinen "Bullshit" aufklären würdest? Wenn ich die vollen 128 Threads ausnutzen will muss ich den Scheduler mit meinem Programm so ansprechen, als hätte ich ein Dual-Socket-System. Das ist mehr Aufwand in meinen Augen.

War ja damals schon beim FX so das Linux damit besser umgehen konnte ...

Ist das nicht überholt? Mal davon abgesehen, dass Win10 WS dieses 64 Thread Limit pro Gruppe nicht hatte, sind diese bei Win 10 Pro (und imho auch Home) doch per Patch aufgehoben worden.

Malkolm schrieb:

Ist das nicht überholt? Mal davon abgesehen, dass Win10 WS dieses 64 Thread Limit pro Gruppe nicht hatte, sind diese bei Win 10 Pro (und imho auch Home) doch per Patch aufgehoben worden.

Zum Vergrößern anklicken....

windows hat halt noch andere dinge die es rumschleppt, seis legacy oder durchsichtige fenster. unter linux kannste den desktop ausschalten und nur per konsole arbeiten. das geht sogut wie nicht bei windows weil eine video ausgabe quasi immer vorhanden ist.
ein 9450@3.2ghz ist unter linux 1/3 als unter windows im ryzen blender benchmark von damals
https://extreme.pcgameshardware.de/...ark-pcghx-sammelt-ergebnisse-58.html#post8694

schneller wie ein i5 3550/ i3 6100.

unter linux gibts kein bestreben nette effekte einzufügen oder leistung zu verschwenden. das können andere mache (maintainer/devs von gnome/kde etc. im gegensatz zu kernelentwickler)


edit//

sterreich schrieb:

Aus dem Windows Artikel

von anandtech:

The Windows and Multithreading Problem (A Must Read) - The 64 Core Threadripper 3990X CPU Review: In The Midst Of Chaos, AMD Seeks Opportunity
Wenn du mich also über meinen "Bullshit" aufklären würdest? Wenn ich die vollen 128 Threads ausnutzen will muss ich den Scheduler mit meinem Programm so ansprechen, als hätte ich ein Dual-Socket-System. Das ist mehr Aufwand in meinen Augen.

Zum Vergrößern anklicken....

man nimmt einfach kein windows bei hpc kram. kenn kein supercomputer wo windows drauf läuft. ob man mehr optimiert hin oder her, man sparrt sich das und lizenzkosten und nimmt einfach linux. fürn support/fachkräft zahlt man weniger auf dauer als bei windows. noch beliebter ist bsd/dragonfly.

Windows unterteilt Systeme mit mehr als 64 Threads in sog. "Processor Groups" zu je 64 Threads. Da viele Anwendungen den Umgang mit solchen "Processor Groups" nicht beherrschen, sprechen sie beim 3990X nur 32 CPUs an.

Der Punkt ist einfach, dass dieser Prozessor ein Monster ist. Und dort, wo solche Monster zum Einsatz kommen, spielt Windows einfach keine besonders große Rolle.

Dass die Maschine zum Spielen völlig überdimensioniert ist, sollte klar sein.

Malkolm schrieb:

Mal davon abgesehen, dass Win10 WS dieses 64 Thread Limit pro Gruppe nicht hatte, sind diese bei Win 10 Pro (und imho auch Home) doch per Patch aufgehoben worden.

Zum Vergrößern anklicken....

Jede Windows Version ist da auf 64 limitiert.

1xok schrieb:

Und dort, wo solche Monster zum Einsatz kommen, spielt Windows einfach keine besonders große Rolle.

Zum Vergrößern anklicken....

Windows für Dekstops....

Tech_Blogger schrieb:

Jede Windows Version ist da auf 64 limitiert.

Zum Vergrößern anklicken....

beleg? Achja, vergas - sowas gibts bei dir nicht, bist ja auf Fakten allergisch.

sterreich schrieb:

Wenn du mich also über meinen "Bullshit" aufklären würdest?

Zum Vergrößern anklicken....

Wenn du danach fragst gerne - nur da du bereits gezeigt hast das du nicht an Fakten interessiert bis - warum sollte ich?
Du hast bereits selbst gezeigt das du lügst - mehr Damit hat sich das ganze ja bereits erledigt.

Windows Enterprise teilt doch gar nicht in Prozessor Gruppen ein.
Langsam wird's echt frech. Holt euch Windows Server mit den Lizenzen bis 64 Kerne, dann kostet Server schon 3000€ separat als OS. 4k € CPU und dann Mr. Geiz sein wollen, weil das Windows 10 für privat limitiert. Microsoft ist noch viel zu entgegenkommend.

Buggi85 schrieb:

Windows Enterprise teilt doch gar nicht in Prozessor Gruppen ein.
Langsam wird's echt frech. Holt euch Windows Server mit den Lizenzen bis 64 Kerne, dann kostet Server schon 3000€ separat als OS. 4k € CPU und dann Mr. Geiz sein wollen, weil das Windows 10 für privat limitiert. Microsoft ist noch viel zu entgegenkommend.

Zum Vergrößern anklicken....

Nicht zu vergessen, jeder client braucht noch nen cal für 119€

Metamorph83 schrieb:

Nicht zu vergessen, jeder client braucht noch nen cal für 119€

Zum Vergrößern anklicken....

Richtig, hier geht's ins Geschäftliche. Auch andere Software ruft Core Lizenzen auf. Man sollte schon wissen für was man 64 Kerne braucht. Aber nur mit der Hardware alleine ist es nicht getan.

Ist ja irgendwann mal Logisch das das Komen mußte.
Erstens WIndows ist aufdie Anzahl der Kerne und Treats beschränkt und Linux / Unix usw. nicht seit Kernel 2,4 gibt es da keine beschränkung auf Kerne und Thread,s .