@ottoman
Angenommen ein Spiel erzeugt eine Last von 400% auf der ganzen CPU (1 Kern = 100%). Dann weiß man nur, dass es mindestens 4 Threads sind. Auch wenn diese durch den Scheduler vielleicht auf 8 Kerne verteilt werden und es aussieht wie 8 Threads.
Jetzt vermute, dass ich langsam weiss, worauf Du rauswillst.
Da müssen wir aber etwas ausholen:
1.Der Begriff Thread ist zweideutig. Es gibt die virtuellen Threads auf einer CPU=2 Stück auf einen Core
2.Es gibt die Bezeichnung kleinerer Unabhängiger Programme, die einen Thread abbilden.
Durch den Scheduler können viele dieser Subroutinen (Threads) unter Anderem auf einem Core- Thread konsolidiert werden oder aber auch verteilt.
Jetzt kommt aber der Punkt. Wäre das Programm nicht auf Multithreading sowohl auf Programm als auch auf Core- Basis optimiert,
würden wir Szenarien erleben, in denen die Command oder Mainthreads ihre Last nicht weiterverteilen, da sequenziell abgebildet.
Bei einer 4 Core- CPU mit HT, optimiert auf 4 Threads sähe das dann so aus:
70% 4% 80% 1% 4% 30% 66% 3%
Dieses Szenario werden sicher einige wiedererkennen
Die Zahlenreihen können beliebig untereinander wechseln, Du wirst aber immer Threads sehen, die nicht ausgelastet werden können.
Dann ist es eine Sache der Messung. Der Afterburner aktualisiert immer den ist- Zustand an einem Messpunkt. Er mittelt also keine Werte.
Es gibt Witcher 3 Videos, da geht unter einem älteren 6- Kerner die Last auch auf bis zu 80% rauf (mit 2x1080 TI).
Spätetens bei solchen Auslastungen steht Deine Argumentation, dass die Software nicht Multicore/Multithreading optimiert ist auf wackeligen Beinen, da dem Scheduler die Wahlmöglichkeit genommen wird, auf "freie" Threads auzuweichen und diese zu pushen, obwohl die anderen Threads, die unter Last stehen, vielleicht noch ein wenig Restkapazität über hätten.
Grüße
Zero