Ryzen 9 5950X: Leistungsbremse SMT? Benchmark-Vergleich 32 Threads vs. 16 Kerne mit Überraschungen

[PCGH-Redaktion]

Jetzt ist Ihre Meinung gefragt zu Ryzen 9 5950X: Leistungsbremse SMT? Benchmark-Vergleich 32 Threads vs. 16 Kerne mit Überraschungen

AMD hat es im Laufe von drei Jahren vom Totgesagten zum Prozessor-Leistungskönig geschafft. Das neue Topmodell Ryzen 9 5950X bricht sowohl in Spielen als auch beim Rendering alle Rekorde - doch geht da noch mehr? In einer speziellen Messreihe klopfen wir nicht nur die Leistung im CPU-Limit ab, sondern sehen uns auch an, inwiefern das standardmäßig aktive Simultaneuos Multi-Threading (SMT) die Spiele-Leistung beeinflusst.

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

Zurück zum Artikel: Ryzen 9 5950X: Leistungsbremse SMT? Benchmark-Vergleich 32 Threads vs. 16 Kerne mit Überraschungen

 

[Blackfirehawk]

Also ich sehe hier größtenteils messtoleranz wenn ich ehrlich bin....

Was man aber durchaus anprangern sollte und auch muss ist das der Windows sheduler nicht smt aware ist.. ich sehe die Problematik weniger bei den Spielentwicklern sondern eher bei Microsoft..

Meines Wissens ist jedoch der core parking Teil smt aware.. theoretisch müsste es eigentlich möglich sein den Energie Sparplan so zu konfigurieren das echte threats bevorzugt werden und smt threats bevorzugt geparkt werden

 

[Firebuster]

Kommt da noch was?

- wie verhalten sich Nvidia Karten?
- wie schaut es ohne SAM aus?

 

[Alex1231985]

Sehr schöner Test! Nur würde ich dasselbe gerne noch mal mit einem 5600X sehen. Gerade jetzt wäre es interessant, ob es an den eh schon vielen vorhandenen Kernen des 5950x liegt. Oder ob die Kleineren Ryzen aus SMT nicht doch einen Vorteil ziehen können

 

[Thomas5010]

Der Bericht gleicht einem Sturm im Wasserglas. Wer auf die Benchmark schaut wird folgendes feststellen: Der Leistungsverlust ist kaum vorhanden und die Empfehlung SMT zu deaktivieren ist zu einseitig. Aus meiner Sicht kann SMT aktiviert bleiben. Der Umweg ins Bios lohnt sich nicht. Besonders wenn später SMT doch wieder aktiviert werden muss, weil einzelne Anwendungen es brauchen. Die Arbeit steht nicht in Relation zum Performancegewinn. Kein Mensch merkt den Unterschied.

 

[Incredible Alk]

Also wenn ich SMT abschalte hab ich einen vermutlich kaum fühlbaren Leistungsvorteil in Spielen. Und roundabout 30% Leistungsverlust in MT-Anwendungen.
Wenn man jetzt noch betrachtet wie oft man mit einem 5950X in Spielen im CPU-Limit ist und welches Anwendungsgebiet die CPU eigentlich hat (und mutmaßlich auch der Workload der Besitzer in die Richtung geht hoffe ich) ist die Entscheidung aber sowas von klar SMT anzulassen klarer gehts gar nicht.

 

[Thomas5010]

Also wenn ich SMT abschalte hab ich einen vermutlich kaum fühlbaren Leistungsvorteil in Spielen. Und roundabout 30% Leistungsverlust in MT-Anwendungen.
Wenn man jetzt noch betrachtet wie oft man mit einem 5950X in Spielen im CPU-Limit ist und welches Anwendungsgebiet die CPU eigentlich hat (und mutmaßlich auch der Workload der Besitzer in die Richtung geht hoffe ich) ist die Entscheidung aber sowas von klar SMT anzulassen klarer gehts gar nicht.

Sehe ich auch so. Völlig uninteressant SMT zu deaktivieren.

 

[Blackfirehawk]

Da ist es sinnvoller je nach Spiel mit processlasso die smt threats auf genau diesen Spiel zu deaktivieren..
Aber Mal ganz ehrlich..es betrifft wirklich nur eine Handvoll spiele wo man überhaupt n vorteil sieht..

Viel interessanter wäre ein FPS und frametime Vergleich in Bezug auf die Nutzung der Chiplets..

Wie verhält sich das ganze wenn ein spiel über 2 Chiplets verteilt ist

Wie verhält es sich mit cppc pref Cores enabled und disabled

Ich zb sehe bei meinem 5950x keinen Performance unterschied ob ein Spiel über beide Chiplets verteilt ist.. auch keine microruckler (GPU Limit gtx1080ti wqhd)

Da merk ich mehr unterschied in FPS und microruckler durch cppc pref core

 

[Horrocko]

Ich fand es in den Frametime-Diagrammen verwirrend, dass die Farbgebung nicht konsistent gehandhabt wurde (SMT AN manchmal orange, manchmal grün und umgekehrt).

 

[h_tobi]

Sehr informativer Artikel.

Habe mir schon so was ähnliches gedacht. Es gab (gibt) da ja mal ein Tool, mit dem man den Programmen die Kerne
zuweisen konnte. Zumindest bin ich der Meinung da mal was gelesen zu haben, als es mit der Mehrkerngeschichte
los ging.
Oder war es über den Taskmanager?


Warum ist M$ nicht in der Lage, dem Scheduler beizubringen, mit wie viel Kernen er Programm X oder Y füttern soll?
Einfach einen kleinen Schalter in den Eigenschaften/der Verrknüpfung, nutze Kerne von - bis oder alle und gut is.
Sooo schwer kann es doch nicht sein oder muss wieder ein "Hobbyanwender" die Arbeit der Firmen übernehmen.

 

[Blackfirehawk]

Sehr informativer Artikel.

Habe mir schon so was ähnliches gedacht. Es gab (gibt) da ja mal ein Tool, mit dem man den Programmen die Kerne
zuweisen konnte. Zumindest bin ich der Meinung da mal was gelesen zu haben, als es mit der Mehrkerngeschichte
los ging.
Oder war es über den Taskmanager?


Warum ist M$ nicht in der Lage, dem Scheduler beizubringen, mit wie viel Kernen er Programm X oder Y füttern soll?
Einfach einen kleinen Schalter in den Eigenschaften/der Verrknüpfung, nutze Kerne von - bis oder alle und gut is.
Sooo schwer kann es doch nicht sein oder muss wieder ein "Hobbyanwender" die Arbeit der Firmen übernehmen.

Processlasso ist so ein Programm

Kannst im Task Manager zwar Affinitys festlegen.. die werden aber nicht gespeichert

 

[h_tobi]

Danke für den Tipp, werd´s mir mal bei Gelegenheit angucken.

 

[Incredible Alk]

Es gab (gibt) da ja mal ein Tool, mit dem man den Programmen die Kerne
zuweisen konnte.

Gibt es seit 1996, nennt sich "Task-Manager".
Du kannst bei jedem beliebigen Prozess die Zugehörigkeit manuell festlegen. Blöderweise halt bei jedem Spielstart aufs neue.

Warum ist M$ nicht in der Lage, dem Scheduler beizubringen, mit wie viel Kernen er Programm X oder Y füttern soll?

Der Scheduler macht das ständig. Und zwar bei allen Hunderten Prozessen die auf deinem PC so laufen gleichzeitig - anhand von sehr komplexen Kriterien auf Hardwareebene. Da ist keine Zeit und auch keine Kapazität um großartig zu implementieren dass es bei Spiel XY (also einem von zig Milionen Programmen) aber jetzt anders sein soll. Das ist die Aufgabe der Entwickler, nicht die von Microsoft. Denn der Entwickler des Spiels kann sehr einfach dem Scheduler sagen wie viele/welche Threads er adressieren soll. Er muss es nur auch machen - da CPUs mit 32 Threads aber eine Verbreitung von <<0,1% haben wird darauf keine Minute der Optimierung verschwendet.

 

[KaterTom]

Na wenn der Unterschied im CPU Limit bei den 1% percentilen schon im niedrigen einstelligen Bereich liegt - und für mich bereits hier vernachlässigbar ist - dann ist es im GPU Limit erst recht egal. SMT bleibt also an!

 

[PCGH_Raff]

Also ich sehe hier größtenteils messtoleranz wenn ich ehrlich bin....

Unsere Benchmarkszenen sind in der Lage, diese Differenzen sauber abzubilden. Ergo keine Messtoleranz, sondern einfach geringe Differenzen.

Kommt da noch was?

- wie verhalten sich Nvidia Karten?
- wie schaut es ohne SAM aus?

Rund um die Balken und Bildchen gibt's noch diese schwarzen Schriftzeichen (ähnlich wie diese hier).

Also wenn ich SMT abschalte hab ich einen vermutlich kaum fühlbaren Leistungsvorteil in Spielen. Und roundabout 30% Leistungsverlust in MT-Anwendungen.
Wenn man jetzt noch betrachtet wie oft man mit einem 5950X in Spielen im CPU-Limit ist und welches Anwendungsgebiet die CPU eigentlich hat (und mutmaßlich auch der Workload der Besitzer in die Richtung geht hoffe ich) ist die Entscheidung aber sowas von klar SMT anzulassen klarer gehts gar nicht.

Ich habe das mit Spielen vs. Anwendungen entsprechend deutlicher im Text hervorgehoben.

MfG
Raff

 

[KaterTom]

Blöderweise halt bei jedem Spielstart aufs neue

Genau das ist ja die Krux, wer will denn das jedes mal durchexerzieren! Man könnte höchstens noch Prozess Lasso verwenden.

 

[Blackfirehawk]

@PCGH_Raff
Sorry hätte schreiben sollen im Bereich von messtoleranz.. nicht daß es messtoleranz ist..
die Unterschiede sind teilweise ja wirklich sehr gering.

Was ich interessant finden würde wäre ein frametime/FPS Vergleich was passiert wenn ein Spiel über 2 Chiplets verteilt ist da sich hier ja einiges zu zen1/2 geändert hat...

Windows neigt nämlich dazu teilweise die Games über beide Chiplets zu verteilen.. obwohl auf dem ersten Chiplet noch Kerne frei sind..


Und einer mit cppc prefered cores an und ausgeschaltet, da dies in den sheduler doch sehr eingreift. Vorallem wenn Hintergrund Anwendungen laufen.

 

[purzelpaule]

Sehr schöner Test! Nur würde ich dasselbe gerne noch mal mit einem 5600X sehen. Gerade jetzt wäre es interessant, ob es an den eh schon vielen vorhandenen Kernen des 5950x liegt. Oder ob die Kleineren Ryzen aus SMT nicht doch einen Vorteil ziehen können

Aus Eigeninteresse wäre das genau das Richtige.
@PCGH_Raff
Habt Ihr die Möglichkeit, hier einen Vergleich zu ziehen?

 

[Mega-Zord]

Für den 5600X und 5800X brauchen wir definitiv auch noch Tests. Sind ja in Arbeit, soweit ich das verstanden habe. Denn SMT beim 5950X zu deaktivieren schmerzt nicht besonders, wenn man sich den Rechner überwiegend zu zocken gekauft hat. Bei einem 5600X möchte man SMT aber sicher nicht abschalten.

Ein Vergleich mit den 10er und 11er Intels wäre noch ganz nett. Da gibt es zwar keine 16 Kerne, aber 6, 8 und 10.

 

[PCGH_Torsten]

Mittlerweile skalieren viele Engines gut bis 16 logische Kerne, spätestens bei einem Sechskerner sollte man SMT anlassen. Ich hoffe, dass Raff entsprechende Benchmarks nachliefert, aber einen deutlichen Hinweis darauf liefern ja bereits Vergleiche zwischen Core i5 9000 und Core i7 8000 oder i5 10000, also Sechskerner ohne respektive mit HT ab Werk.

Gibt es seit 1996, nennt sich "Task-Manager".
Du kannst bei jedem beliebigen Prozess die Zugehörigkeit manuell festlegen. Blöderweise halt bei jedem Spielstart aufs neue.
Anhang anzeigen 1349727

Raff müsste das bei Gelegenheit mal nachmessen, aber ich glaube nicht, dass sich hiermit der gewünschte Effekt erzielen lässt. Im Gegensatz zu den Aussagen einiger vorangehenden Posts ist der Windows-Scheduler seit langem SMT-Aware und legt Threads bevorzugt auf jeden zweiten Kern, sodass alle physisch vorhandenen Recheneinheiten ausgelastet werden. Das nützt aber nichts, wenn ein Spiel für jeden logischen Kern einen Thread spawnt, denn Windows kann nicht vorhersagen welcher davon hohe Rechenlasten erfordern wird und welche anderen Threads gut auf einem physischen Prozessor parallel bearbeitet werden können. Da man die Zuordnung erst nach Start einer Anwendung definieren kann, wenn diese bereits die Zahl der absolut verfügbaren Kerne abgefragt hat, lässt sich dieser Fehler nicht nachträglich korrigieren. Wenn das Spiel 64 Threads auf einem 16-Kerner gespawnt hat, wird der Prozessor im Schnitt 4 Threads pro physischem Kern bearbeiten müssen. Ob man Windows erlaubt, je 2 davon auf 32 logische Kerne zu verteilen oder ob man es auf 16 logische Kerne zu je 4 Threads einengt, ändert nur die Verwaltungsebene. In letzterem Fall kann die CPU nicht einmal via SMT zwischen zweimal zwei Threads jonglieren, sondern der Windows-Scheduler muss alle vier Workloads je Kern verwalten, was er als Software nur halb so gut kann.

Anders dagegen die Deaktivierung im UEFI: Hier werden dem Spiel schon zum Start 16 Kerne gemeldet und es kann seine Task-Struktur darauf optimieren. Der zusätzliche Overhead, der für das Spawnen einer größeren Zahl kleiner Threads entsteht, entfällt komplett und in Spielen, in denen diese Koordination ein Problem war, stellt sich ein Performance-Gewinn ein.