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

wenn man also eh nur alte Games zockt,da gillt das gleiche wie hier. Z.b ein Borderland 1 von 2009 zeigt ebenso dieses verhalten zwischen 4 Kerne und 4+ht gibt es halt keine Unterschiede mehr.Darum kann man auch da dann HT bzw smt abschalten.Wenn also mein CPUs mal alle kaputt gehen,kann ich auch in nur lauter 4 kerner umrüsten.Das mag zwar dann ein downgrade sein,aber wenn man halt nicht mehr braucht,dann nutzt einem mehr Kerner auch nix mehr.
 
Aber das Thema Threads und Kerne ist recht komplex. Dass Kerne schlecht ausgelastet werden kann 100.001 Ursachen haben. Das kann an schlechter Programmierung liegen, an der CPU selbst, an der Implementierung des Hyperthreading, am Threadscheduler des OS, ...

Besonders krass ist es, wenn dabei z.B. an .net denkt: Innerhalb der .net Runtime läuft die "Concurrency Runtime". Diese wägt u.a. anhand vom Systemzustand und von Codeanalysen ab, ob die Mehrkosten für das Erstellen und Verwalten eines Threads die "Aufgabe" aufwiegt. Sollte also das Erzeugen und Verwalten eines Threads teurer sein, wird die Aufgabe synchron ausgeführt und kein separater Thread gestartet. Auch dann nicht, wenn die Aufgabe selbst als Thread programmiert wurde. :ugly:
 
"Mehrkernwette": Das prominenteste Beispiel, das mir dazu einfällt, ist die Entscheidung zwischen Core 2 Quad Q6600 und Core 2 Duo E8400 vor vielen Jahren. Die Dinger waren eine Weile vergleichbar teuer, also stellte sich die Leistungsfrage (während die Leistungsaufnahme trotz des G0-Steppings klar für den Wolfdale sprach). Mittlerweile sucken beide, keine Frage. Zwischendrin gab es jedoch eine Zeit, in der man mit vier optimierten Kentsfield-Kernen irgendwo zwischen 3,2 und 3,6 GHz klar besser fuhr als mit einem Wolfdale @ 4+ GHz. Das passiert derzeit zwischen 4- und 6-Sechskernern und wird in einigen Jahren auch die Achtkerner einholen.

MfG
Raff
BF Bad Company 2 aus 2010 war so ein Titel, der die Spreu vom Weizen getrennt hat. Im MP wurde ein E8400 auch mit OC gern mal voll ausgelastet, mit entsprechend "tollen" Frametimes.

Wie im von dir soeben zitierten Post beschrieben:
Es gibt kein "mindestens" und selbst wenn es das gäbe, bräuchte es zusätzlich noch ein "maximal". In der Praxis geht es aber um das Zusammenspiel zwischen Spiel, Scheduler und CPU. Die Entwickler kennen das Spiel, aber nicht die Gegenseite – erst Recht nicht mit Blick auf die Zukunft.
Ein Minimum kann und wird doch offenbar auch von machen Spielen gesetzt. Manche Spiele starten doch auf 2T CPUs z.B. nicht. Meine Überlegung war, dass durch das Begrenzen von Threads der Scheduler weniger gezwungen wird, einen Kern mit zwei (zeit)kritischen Threads zu belegen.

Wenn Anno keine zusätzlichen Threads für weitere Kerne spawnt (oder diese keine Konflikte verursachen) kann die manuelle Zuweisung genauso helfen, wie eine UEFI-Änderung, ja. Wenn der Verwaltungsoverhead für viele Threads mit jeweils nur geringer Rechenlast das Problem ist, muss der Zugang zu den Kernen dagegen schon beim Start verweigert werden – das kann der Taskmanager nicht bieten, da hilft nur das UEFI.
Dann wäre doch eine manuelle Auswahlmöglichkeit am besten, oder nicht? Warhammer Vermintide 1 und 2 bieten so eine Möglichkeit sogar.

Das ist eher ein Situation wie zwischen E8400 und QX9650: Beide mit hohem Takt, einer mit doppelt so vielen Kernen aber auch so schweine viel teurer, dass die E8400-Käufer ein paar Jahr später einen i5-2500K nebst Board vom gesparten Geld kaufen konnten. Und der ist gegenüber einem QX9650 klar vorzuziehen.
Ja, es ist schon lange nicht mehr sinnvoll reine Spiele CPUs mit (zu weitem) Blick in die Zukunft zu kaufen und sehr viel Geld dafür auszugeben. Es recht unter Betrachtung der Kernzahl. Der Q6600 hat sich nur mit OC gelohnt (im Vergleich zum E8400). Der Thuban nie so richtig. Bei Ryzen 1700(X) und 8700k hat sich das Blatt auch noch lange nicht zu Gunsten des AMD gewendet.
 
Bitte nicht zum 20000sten Mal diese Diskussion :heul:
Es geht in dem Test um SMT, nicht um einen CPU Test allgemein.
Allgemein spielt niemand auf 720p.
Allgemein spielt es keine Rolle, ob SMT an oder aus ist!
Ist ja schön zu sehen, wie Spiele mit SMT 5% langsamer werden.
Aber
A: Wuste das schon jeder vorher. Es gibt 100rste Test dazu auf Youtube
B: Schaltet man kein SMT aus im BIOS! Denn Anwendungen profitieren vom SMT sehr stark. Eine SMT Einheit bringt 30% einer echten CPU.
 
Was den Meisten wohl noch nicht aufgefallen ist, SMT Off beeinflusst auch die Latenzen.
Beim 3900X wurde nur L3 schlechter. Beim 5900X wird auch der L3 schelchter, aber die Memory Latenz wird verbessert.
Zumindest in meinen Tests. Hier 2 Beispiele mit und ohne SMT. Rest ist gleich, optimierter 3200 CL14 RAM.

mit SMT
5900X RAM CL14 3200 fast.png



ohne SMT
5900X SMT OFF RAM CL14 3200 fast.png
 
Spieleentwickler wissen zwar, womit ihre Software zurecht kommt, sie wissen aber nicht, was die CPU kann. Meinem Wissen nach meldet das Betriebssystem der Software keine Details über den Prozessoraufbau
Es lässt sich seit langem abfragen, wie viele physikalische und wie viele logische Kerne die CPU besitzt. Erwartet man dann eine "übliche" x86 CPU im Windows Bereich, hat diese max. ein Verhältnis von 2:1 (logisch zu virtueller Kern). Architekturen wie Buldozer kann man da im Zweifel genauso ignorieren wie die ersten Treadripper, und Seerver-CPU mit 4 virt. Kernen je physiklaischem genauso wie Big-Little CPUs.

Wenn die Entwickler wissen, dass ihr Spiel/ihre Engine nicht gut mit HT umgehen kann, kömnen sie die Threads entsprechend verteilen oder wenigstens die Anzahl der Threads begrenzen und hoffen, dass Microsoft die übrige Arbeit für sie getan hat.

In der Praxis spart man sich den ganzen Aufwand und passt die Spielkonfiguration entweder gar nicht an die vorliegende Hardware an, sondern entwickelt für einen allgemeinen Durchschnitt
Die Spiele scheinen eher für die minimalste Kombi aus CPU+GPU optimiert, auf der das Spiel noch laufen soll. Den Rest hat dann gefälligst jemand anderes für den auch so gebeutelten Spieleentwicker (wohl oft eher den Projektmanager oder Geldgeber) zu erledigen. Ist ja auch kein Wunder bei Spielen, die wohl oft beim Kunden reifen.

Allgemein gilt aber ohnehin, dass eine Ausreizung von SMT auf schwachen CPUs eine gute Idee ist und dass die Performance auf guten CPUs die Entwickler reichlich wenig interessiert, weil die sowieso meist im GPU-Limit stecken.
Klar, also löst es wieder die HW und der Geldbeutel der Gamer. Die scheinen ja sowieso alles zu akzeptieren.

Es würde nicht reichen allein die Menge an Threads zu begrenzen.
Ja und? Das am Anfang genannte Tool pinnt die Threads wohl einfach an die passenden Kerne, wie es auch auf die alten Threadripper optimierte Anwendungen tun, damit sie ein amok laufender Scheduler nicht wieder irgnedwo hin verschiebt.

Besonders krass ist es, wenn dabei z.B. an .net denkt: Innerhalb der .net Runtime läuft die "Concurrency Runtime". Diese wägt u.a. anhand vom Systemzustand und von Codeanalysen ab, ob die Mehrkosten für das Erstellen und Verwalten eines Threads die "Aufgabe" aufwiegt. Sollte also das Erzeugen und Verwalten eines Threads teurer sein, wird die Aufgabe synchron ausgeführt und kein separater Thread gestartet. Auch dann nicht, wenn die Aufgabe selbst als Thread programmiert wurde. :ugly:
Das ist mir zwar selbst mit einem Threadpool noch nicht passiert, aber dafür kann man unter .NET immer noch Threads händisch erzeugen. Und wenn der dann mal läuft, wird er auch laufen gelassen. Ich komme aber auch nicht auf die Idee mir Mutithraed-Programmierung anzutun, wenn es nicht zwingend nötig ist. Dafür habe ich aber shcon oft genug die Threadanzahl beschränkt wenn aus den Tests mit den drei vorhandenen PCs/Laptops klar war, dass dies bei gewisser HW-Aussattung bedeutend sinnvoller/performanter ist.
 
BF Bad Company 2 aus 2010 war so ein Titel, der die Spreu vom Weizen getrennt hat. Im MP wurde ein E8400 auch mit OC gern mal voll ausgelastet, mit entsprechend "tollen" Frametimes.

Ein Minimum kann und wird doch offenbar auch von machen Spielen gesetzt. Manche Spiele starten doch auf 2T CPUs z.B. nicht. Meine Überlegung war, dass durch das Begrenzen von Threads der Scheduler weniger gezwungen wird, einen Kern mit zwei (zeit)kritischen Threads zu belegen.

BF MP war und ist in nahezu jeder Generation ein Multicore-Killer. Ich verstehe bis heute nicht wieso. Wenn man vergleicht, was um die Jahrtausendwende an Multiplayer-Shootern komplett auf einem Kern lief und wofür der BF-MP zwei beziehungsweise mittlerweile eher vier zusätzliche Kerne gegenüber BF-SP frisst, ist das Ergebnis einfach nur absurd.

Die von dir vorgeschlagene, manuelle Threadbegrenzung würde High-End-Prozessoren massiv einbremsen. Wenn eine Engine auf einem 5800X mit SMT etwas schlechter läuft als auf einem 5800X ohne SMT und deswegen hart auf eine Threadzahl limitiert wird, die trotz SMT sauber berechnet wird, dann wäre überhaupt erst einmal abzuwarten, ob der Scheduler bei weiterhin aktivem SMT damit überhaupt die Performance der SMT-losen Konfiguration erreicht. Fest steht aber von vorneherein, dass dieses Spiel auf einem 5950X kaum noch besser als auf einem 5800X performen wird.

In dem Vergleich ist das erstmal "nur" schlechte Presse, aber setzen wir uns mal in eine Zeitmaschine und reisen in den Dezember 2016: Mainstream wird von Skylake dominiert, im HEDT bringt Broadwell E eine ähnliche pro-Kern-Leistung, aber deutlich mehr Kerne. Spiel X skaliert jenseits von sechs Kernen mit SMT schlecht und wird deswegen vom Entwickler auf diese Grenze festgeschnürt. Ein halbes Jahr später erscheint der Ryzen 7 1800X mit einer geringeren pro-Kern-Leistung, aber 16 logischen Prozessoren. Spiel X weigert, sich diese auszunutzen, obwohl bei der geringeren pro-Kernleistung die zusätzliche Rechenleistung trotz Overhead gut genutzt werden könnte. AMD-Prozessoren skalieren jenseits von Ryzen 5 gar nicht mehr und der kann gerade eben so mit Kaby Lake mithalten. Es resultiert der letzte Shitstrom, den dieser Spielepublisher jemals erleben wird, bevor er zumachen kann.

Und wozu das Ganze? Damit ein sehr kleiner Kreis von Luxus-CPU-Besitzern nicht einfach "sehr gute Fps", sondern noch einmal 5 Prozent mehr hat. Wie gesagt: Aus Entwicklersicht ein absolut bescheuerter Optimierungsansatz. Wichtig ist, dass ein Spiel auf einer Einsteiger- bis Mittelklasse-CPU optimal läuft. Die haben aktuell acht bis zwölf logische Kerne. Alles, was darüber hinaus geht ist optional und muss nicht optimal skalieren. Natürlich wäre es toll, wenn ein Titel einfach überall perfekt laufen würde, aber dafür muss man eben Architekturspezifisch an die Sache rangehen.
 
Was den Meisten wohl noch nicht aufgefallen ist, SMT Off beeinflusst auch die Latenzen.
Beim 3900X wurde nur L3 schlechter. Beim 5900X wird auch der L3 schelchter, aber die Memory Latenz wird verbessert.
Zumindest in meinen Tests. Hier 2 Beispiele mit und ohne SMT. Rest ist gleich, optimierter 3200 CL14 RAM.

mit SMT
Anhang anzeigen 1350544


ohne SMT
Anhang anzeigen 1350545

Das liegt an den tollen Schutzmaßnahmen gegen Side-Channel-Angriffe!
Wenn man unter Windows diese abschaltet, wird der Rechner um 5% schneller.
 
Also das mit Memory Latenz wird besser bei SMT Off war Käse.
Hab nun mit SMT 60,1 ns, find ich ganz gut für ein Ryzen mit nur 3200 MHz RAM.
L3 Cache wird aber auf jedenfall schlechter.
Die Latenz wackelt wie Kuhschwanz. Hatte nun mehrere Werte zw. 60 und 64 ns

Paar Games kurz getestet, quasi kein Unterschied mit SMT an aus.
Beim 3900X hatte ich SMT wieder angemacht, weil ich bei einem Spiel deutlich schlechter Frametimes gemessen hatte.
 
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

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.

Tatsächlich müsste man, gut 5 Minuten investieren. Wenn man den wüsste wie sein Spiel Hardware auslastet. Was der Job des Spieleherstellers ist.
Spiel kann 4 Threads nutzen? 4 Kerne voll belasten wenn die GPU nicht limitiert?
Deklariere es. Dann kann der MS-Sheduler das zuweisen. Ne Handvoll If-Regeln.
Das der Sheduler Mist ist sehe ich öfter bei anderen Spielen wo abwechselnd die Kerne 0%→100%→0→100... springen. Und das im Sekundentakt.

Bis heute sind sowhol die Publisher als auch MS in der Hinsicht (Achtung Wortwitz) Kerninkompetent.
 
BF MP war und ist in nahezu jeder Generation ein Multicore-Killer. Ich verstehe bis heute nicht wieso. Wenn man vergleicht, was um die Jahrtausendwende an Multiplayer-Shootern komplett auf einem Kern lief und wofür der BF-MP zwei beziehungsweise mittlerweile eher vier zusätzliche Kerne gegenüber BF-SP frisst, ist das Ergebnis einfach nur absurd.
Wäre doch mal ein interessantes Thema für ein Interview!:daumen:

Die von dir vorgeschlagene, manuelle Threadbegrenzung würde High-End-Prozessoren massiv einbremsen. Wenn eine Engine auf einem 5800X mit SMT etwas schlechter läuft als auf einem 5800X ohne SMT und deswegen hart auf eine Threadzahl limitiert wird, die trotz SMT sauber berechnet wird, dann wäre überhaupt erst einmal abzuwarten, ob der Scheduler bei weiterhin aktivem SMT damit überhaupt die Performance der SMT-losen Konfiguration erreicht. Fest steht aber von vorneherein, dass dieses Spiel auf einem 5950X kaum noch besser als auf einem 5800X performen wird.
Keine Frage, aber nur unter der Prämissen, wenn es mit SMT sauber läuft.

In dem Vergleich ist das erstmal "nur" schlechte Presse, aber setzen wir uns mal in eine Zeitmaschine und reisen in den Dezember 2016: Mainstream wird von Skylake dominiert, im HEDT bringt Broadwell E eine ähnliche pro-Kern-Leistung, aber deutlich mehr Kerne. Spiel X skaliert jenseits von sechs Kernen mit SMT schlecht und wird deswegen vom Entwickler auf diese Grenze festgeschnürt. Ein halbes Jahr später erscheint der Ryzen 7 1800X mit einer geringeren pro-Kern-Leistung, aber 16 logischen Prozessoren. Spiel X weigert, sich diese auszunutzen, obwohl bei der geringeren pro-Kernleistung die zusätzliche Rechenleistung trotz Overhead gut genutzt werden könnte. AMD-Prozessoren skalieren jenseits von Ryzen 5 gar nicht mehr und der kann gerade eben so mit Kaby Lake mithalten. Es resultiert der letzte Shitstrom, den dieser Spielepublisher jemals erleben wird, bevor er zumachen kann.
Vielleicht erinnere ich mich falsch, aber genau das, was du beschreibst, war/ ist doch zu beobachten (ohne den genauen Grund zu wissen). Die größeren Ryzen hatten sich kaum von den kleineren absetzen können und hatten da Problem mit SMT. PCGH hat damals dazu geraten SMT bei Ryzen abzuschalten - auf jeden Fall bei den 8-Kernern.

Und wozu das Ganze? Damit ein sehr kleiner Kreis von Luxus-CPU-Besitzern nicht einfach "sehr gute Fps", sondern noch einmal 5 Prozent mehr hat. Wie gesagt: Aus Entwicklersicht ein absolut bescheuerter Optimierungsansatz. Wichtig ist, dass ein Spiel auf einer Einsteiger- bis Mittelklasse-CPU optimal läuft. Die haben aktuell acht bis zwölf logische Kerne. Alles, was darüber hinaus geht ist optional und muss nicht optimal skalieren. Natürlich wäre es toll, wenn ein Titel einfach überall perfekt laufen würde, aber dafür muss man eben Architekturspezifisch an die Sache rangehen.
Vielleicht war meine Überlegung nicht zu Ende gedacht. Ziel sollte es sein, dass CPUs mit vielen Kernen (und SMT) zumindest keinen Nachteil haben sollten, während CPUs mit weniger Kernen effizienter genutzt werden könnten. Dabei geht es (mir) auch weniger um die Durchschnitts-FPS, sondern um konstante Ausgabe der Bilder.
 
Origins auf jeden Fall, dort habe ich ohne SMT 10-15fps mehr. Cyberpunk eher weniger und RDR2 kann ich gerade nicht genau sagen, läuft aber sauber mit einem 3600 ohne SMT. Ich schau mir das die Tage genauer an, Teste den 3600 und meinen 5900X.
Ich habe den Fall Hyperthreading / SMT an / aus mal mit meinem PC in Origins nachgestellt.
Mit SMT gibt es einen wesentlich ruhigeren Verlauf der Bildrate. Durch die voll ausgelastete CPU werden die Frametimes ohne SMT beim 6-Kerner schon wesentlich schlechter.
Hierzu bin ich direkt nach dem Laden 10 Sekunden zum Forum in Kyrene gelaufen, habe 20 Sekunden gewartet und dann jeweils das Bild gemacht (maximale Details ohne Begrenzung der FPS und keine dynamische Auflösung).

System: siehe Profil, Link zu sysprofile in Signatur
Ryzen 2600 @3,9 GHz allcore bei 1,13 V (Cool&Quiet / PSS deaktiviert, global_CState aktiviert, AMD Ryzen Balanced Energiesparplan)
MSi X470 Gaming Plus Max, Beta-BIOS HB1
2x 16 GB DDR4-3200 16-18-18-39-58 1T, single ranked (ohne Geardown-Modus und ohne Bankgroupswap)
RoG Strix GTX 1070 @OC-BIOS (461.09)
Realtek Audio-Treiber vom 03.11.20 (6.0.9057.1)
Windows 10 20H2 Build 19042.746

Ja, es ist schon lange nicht mehr sinnvoll reine Spiele CPUs mit (zu weitem) Blick in die Zukunft zu kaufen und sehr viel Geld dafür auszugeben. Es recht unter Betrachtung der Kernzahl. Der Q6600 hat sich nur mit OC gelohnt (im Vergleich zum E8400). Der Thuban nie so richtig. Bei Ryzen 1700(X) und 8700k hat sich das Blatt auch noch lange nicht zu Gunsten des AMD gewendet.
Ja, als reiner Gamer ist es schwer einen guten Mittelweg zu finden.
Man konnte zum Release einen 3800X kaufen, der aber jetzt gegen einen 5600X verlieren würde.
Ein 3950X / 5950X wäre für einen ausschließlich für Gaming verwendeten PC fast eine Fehlinvestition, hat durch die 16 physischen Kerne bei deaktiviertem SMT aber durchaus seinen Reiz.

Ich stelle Mehrpreis und Mehrleistung immer gegenüber, daher bin ich auch noch so zufrieden. Der Ryzen 1600 im Zweit-PC kostete brachiale 74€ und mein 2600 90€, dabei habe ich sogar ein gutes Exemplar erwischt.

Alles in allem sind derzeit meiner Meinung nach 6 bis 8 hoch taktende Kerne mit guter IPC dieser goldene Mittelweg - rein bezogen auf Gaming. Bei CPUs mit 6 Kernen und weniger ist SMT in den meisten Fällen hilfreich.
Ab 12 Kernen sollte man auf SMT verzichten.
 

Anhänge

  • ACOrigins_Zen_SMT-on.jpg
    ACOrigins_Zen_SMT-on.jpg
    584,3 KB · Aufrufe: 47
  • ACOrigins_Zen_SMT-off.jpg
    ACOrigins_Zen_SMT-off.jpg
    582,5 KB · Aufrufe: 47
Zuletzt bearbeitet:
Habe ich nicht ausprobiert, so viel Zeit hatte ich im Urlaub dann doch nicht. :D Eventuell hat aber ein anderer hier schon damit herumgespielt. :-)

MfG
Raff
 
Warum sind die Spielentwickler nicht zu sowas in der Lage, das ist Aufgabe der Anwendung, und dort auch recht problemlos lösbar. Die Entwickler wissen, mit wie vielen Threads ihre (ja offensichtlich zu dumme) Software zurecht kommt.

Anfang? Seit mind. 2010 (SandyBridge) haben Spiele (und schlecht programmierte Anwendunge) Probleme damit. Das sind 10 Jahre in denen die Entwickler der Spiele hätten reagieren können.
Bei der Spieleentwicklung, geht es offensichtlich nicht darum, ein technisch einwandfreies Produkt abzuliefern.
Nach 10 Jahren sollte das jedem Konsumenten klar sein?
 
Zurück