Wenn ich lese, dass einzelne Threads manuell auf einzelne Kerne genagelt werden, sind Probleme zu erwarten, weil die Automatiken eben nicht mehr funktionieren. Da sind bei der Arrow-Lake-Einführung wieder einige Spiele negativ aufgefallen, weil sie blind die "ersten acht" Kerne angesprochen und sich somit teilweise selbst auf die E-Cores geschoben haben, unter Umgehung des Thread Directors. Ich beschäftige mich aber nicht intensiv genug mit Alpha-Versionen um zu wissen, ob hier seitens des Spiels ins Scheduling eingegriffen wird. Das SMT-Deaktivierung als sinnvoll erachtet, spricht aber schon mal dafür, dass eine Software entweder extrem gut optimiert ist (selten: Kern ist ohne SMT-Nutzung schon zu 100 Prozent ausgelastet) oder aber eine Katastrophe die beispielsweise so viele Threads spawnt, dass der zusätzliche Verwaltungsaufwand mehr Rechenleistung kostet als durch die feinere Verteilung freigesetzt wird. Das sind dann typischerweise Titel, die sehr viele Kerne "aus-" oder zumindest "belasten" können, aber schon sehr früh keine höheren Fps mehr daraus ziehen. (Vor Rzyen 7000 wollten @PCGH_Dave und ich wollten mal Spiele mit einem "quasi-"monolithischen 56-Kerner daraufhin testen, aber Sapphire Rapids war einfach immer so viel langsamer als Raptor Lake, dass es albern wirkte.)
Was darüber hinaus noch sein kann, aber kein Thema für das Thread-Scheduling ist (leider – eigentlich sollte man es dort berücksichtigen):
Wenn Frametimes an einem einzelnen oder zumindest sehr wenigen, sehr großen Threads und somit an der Single-Core-Leistung kleben, dann spielen Turbo-Modi eine wichtige Rolle. Es kann in solchen Fällen sinnvoll sein, Power-Limit- (oder Temperatur-) Reserven freizuschaufeln, in dem man möglichst große Teile des Prozessors ganz außer Betrieb nimmt. Dabei ist es ziemlich egal, welche Teile das sind; sogar "weniger P-Kerne" können sich lohnen. (Probe, falls jemand Spaß an Alpha-Benches hat: Maximaltakt auf niedriges Niveau, z.B. 4 GHz, reduzieren. Wenn es dann auf einmal keinen Unterschied mehr gibt, war die nicht Art, sondern schlicht die Anzahl der aktiven Kerne ein Problem.)
Was darüber hinaus noch sein kann, aber kein Thema für das Thread-Scheduling ist (leider – eigentlich sollte man es dort berücksichtigen):
Wenn Frametimes an einem einzelnen oder zumindest sehr wenigen, sehr großen Threads und somit an der Single-Core-Leistung kleben, dann spielen Turbo-Modi eine wichtige Rolle. Es kann in solchen Fällen sinnvoll sein, Power-Limit- (oder Temperatur-) Reserven freizuschaufeln, in dem man möglichst große Teile des Prozessors ganz außer Betrieb nimmt. Dabei ist es ziemlich egal, welche Teile das sind; sogar "weniger P-Kerne" können sich lohnen. (Probe, falls jemand Spaß an Alpha-Benches hat: Maximaltakt auf niedriges Niveau, z.B. 4 GHz, reduzieren. Wenn es dann auf einmal keinen Unterschied mehr gibt, war die nicht Art, sondern schlicht die Anzahl der aktiven Kerne ein Problem.)
(nichts für ungut 
)
.gif "sm_B-) :-)")
(Anhang)
