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.
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 und wie wir spätestens seit Bulldozer und Threadripper wissen, kann man solche Angaben ohnehin schwer verallgemeinern. Ein Spiel hätte zwar die Möglichkeit, den CPU-Namen abzufragen und dann spezifische Optimierungen zu laden, aber auch das würde zwangsläufig nur für Prozessoren funktionieren, die älter als das Spiel sind. 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, oder man spawnt Threads passend zur Anzahl der gemeldeten logischen Kerne. Dass der Prozessor Probleme bekommt, wenn man diese tatsächlich auslastet, ist dann aus Sicht der Entwickler ein Problem der Hardware-Hersteller. 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.
Danke PCGH für den Test.
Woran liegt das eigentlich das SMT (mit vielen Kernen) in Games bremst? Ist da das OS dran Schuld?
Das die Threads nicht optimal genutzt werden können?
Da gibt es mehrere Möglichkeiten, die sich von außen kaum trennen lassen:
- Zusätzlicher Verwaltungsoverhead
- Nicht optimale Kombination von Threads auf einzelnen Kernen
- Sich änderndes Turbo-Verhalten
- Ineffizientere Cache-Nutzung
- Behinderung von System-Threads
etc.
Auf der anderen Seite steht die Frage, wieviel Mehrleistung durch zusätzliche Parallelisierung überhaupt noch herausholbar ist und wie viele Wartezeiten es im ersten Thread pro Kern überhaupt gibt, in denen an einem zweiten gearbeitet werden könnte. Je mehr Kerne man ohnehin schon hat, desto geringer ist in der Regel der Nutzen und desto größer ist die Gefahr von Problemen. Irgendwann überwiegen dann die Nach- die Vorteile.