Ja ja, sag es doch gleich: Lieber 8 starke Kerne, als 16 Luschen!
Das ist nicht der Punkt - wenn die 16 "Luschen" bei Belastung von nur 8 Einheiten entsprechend ähnlich schnell agieren, wie die 8 starken Kerne - gibts auch kein Problem.
Nur hier wird wieder so wirklich alles über einen Kamm versucht zu ziehen ohne auch nur ansatzweise zu differenzieren.
Messung per FPS ist ne äußerst ungünstige Methode wenn man CPU Multithread Skalierungsfähigkeiten ermitteln möchte in Games. Warum? FPS sind das Resultat von strikt sequenziell in einer fixen Reihenfolge erzeugen Einzelergebnissen. Da ist mit MT sogut wie gar nichts zu holen. Und wenn man sich auf den Kopf stellt, wird sich da nix ändern. Auch nicht, dass die Programmierer alle zu Dummen und Faulen Dödeln gemacht werden, weil irgendwelche Forenprofis meinen, das wäre alles kein Problem.
Denn was hier nicht verstanden wird - es ist ein riesiger Unterschied eine Basisanforderung so hoch zu schrauben, dass das nur mit so und so vielen Cores/Threads ansatzweise auf Leistung kommt im Vergleich zu dem, was man hier eigentlich will - nämlich FPS in bisher untypischen Regionen.
Weiter oben viel schonmal so ein Schwenk in die richtige Richtung. Auf der Konsole gibt sich der Spieler häufig mit sehr niedrigen FPS zufrieden während auf dem PC häufig ganz andere Ansprüche anzutreffen sind. 30 FPS oder so sind nicht selten bei den Konsolen. Deutlich über 100 beim gleichen Spiel auf dem PC bedingt hier, bei exakt gleichem Backend eine um gut und gerne Faktor 3-4 höhere Performance in Form von mehr Abarbeitungen der gleichen Sache in der selben Zeit (nicht aber in Form von mehr zusätzlichen Arbeiten in der gleichen Zeit) Genau das ist aber das Problem.
Es ist absolut gar kein Problem, war es nicht, wird es auch nie sein, mehr Arbeit in eine Software reinzubauen und damit mehr Berechnungen, die am Ende dafür sorgen, dass mehr Prozessorkerne/threads auch ausgelastet werden. ABER, es ist ein ziemlich schwer zu lösendes Problem eine definierte Aufgabe so umzubauen, dass die Abarbeitungsgeschwindigkeit dieser mal eben so mehr oder weniger beliebig über die Prozessorbreite skaliert. Bei Games ist das noch viel mehr ein Problem als in anderer Software, denn Games ticken nach gewissen fix vorgegebenen Parametern. Die KI Berechnung lässt sich intern 1a per Multithreading beschleunigen, ABER, das Spiel möchte keine schlauer werdende KI bei mehr Bumms des PCs, sondern es möchte exakt DIE eine Art KI in der exakt einen Geschwindigkeit mit der exakt definierten Berechnungsmenge pro Zeiteinheit. Geht es schneller als minimum notwendig, wartet man auf den nächsten Durchlauf.
Simples Beispiel dazu - wohl sogut wie jeder hier kennt wohl das Thema Netcode/Tickrate bei Online Shootern. Das ist ein Paradebeispiel dafür... Der Wert ist fix. Zumindest so fix, dass er nicht über die CPU Geschwindigkeit skaliert. Als Anwender MUSS man dafür sorgen, dass der PC entsprechend schnell ist um minimal so und so viele Daten verarbeiten zu können. Drüber? Verpufft die Mehrleistung.
-> das findet sich in vielen verschiedenen Bereichen im Gaming, sei es KI, sei es Physik, sei es die Gamelogik im Backend usw.
Sound = 1 Thread, GPU I/O = 1 Thread, Objekte/Map = 1 Thread, Physik = 1 Thread, pro AI = 1 Thread, etc, etc, etc
Da machst du es dir zu einfach - normal arbeitet man dort mit so einer Art Threadpool oder Workern, die von irgend einem Steuerthread "gesteuert" werden. Multithreading ansich ist in Games seit sonst wie vielen Jahren schon gängige Praxis und funktioniert auch absolut gesehen sehr gut. Nur wollen die Leute eben eine FPS Steigerung - was durch MT aufgrund der sequenziellen Abarbeitung so nicht wirklich funktioniert.
Was man machen kann (und was vielfach auch getätigt wird) - man baut mehr Berechnungen dran. Das hebt die Basisanforderung an. So dass bei Modellen nahe der Basis sehr wohl eine recht gute Threadskalierung einsetzt - wenn aber alle Berechnungen maximal breit verteilt sind und jedes Teilstück nen eigenen CPU Core belastet, ohne von anderen Threads beeinflusst zu werden, gibts natürlich keine Skalierung mehr -> das ist dann der Punkt, den du mit gewisse Grenze meinst.
Unabhängig davon hat das aber nix mit einer unmöglichen Aufteilung zu tun - die Aufteilung funktioniert schon und MT wird auch stark genutzt in diesem Bereich. Allerdings vergessen die Profis hier gern, dass neben ihren 12C Ryzen CPUs noch Leute auf dem Planeten leben, die vllt mit nem 4C/4T Prozessor spielen wollen. Auch da muss/soll das Spiel funktionieren. -> hier kommt dann das FPS Skalierungsproblem zum tragen. Mehr CPU Bumms macht zwar schnellere Berechnungen - aber schnellere Berechnungen gerade beim Backend und in Teilen beim Frontend bringen lange nicht mehr FPS. Denn da limitiert vllt nur die API oder kein Plan, der Treiber oder weis der Geier was...