Es wurde ja schon geschrieben....es gilt nicht pauschal für alle Spiele und Anwendungen, aber die Unterscheidung ist schon überwiegend zutreffend.
Zum Cache und Arbeitsspeicher....mal grobe Beispiele von AM4 AMD CPUs...nach meinem Wissensstand zu den Thema:
L1 Cache ist winzig aber die 1ns Reaktionszeit ist ausreichend, um zwischen dem Zeitpunkt wo Daten angefragt werden und wenn sie in der Pipeline gebraucht werden, zu liefern, so dass es nicht zum Stillstand der Pipeline kommt.
L2 Cache ist mit ca. 3ns nicht immer ausreichend schnell, aber er enthält alles was der L1 Cache hat + ältere Daten, oder Daten die nicht in L1 gepasst haben.
L3 Cache. Hier wird hineingeschoben, was aus den L2 Caches verdrängt wird oder für diesen zu groß ist und Daten bleibt aufgrund der Größe deutlich länger "am leben". Mit ca. 9ns Antwortzeit ist er aber auch träger...dafür teilen sich mehrere Kerne den L3 Cache und das kann helfen wenn mehrere Threads an den gleiche Daten arbeiten.
Und der Arbeitsspeicher hat je nach Geschwindigkeit zwischen 60 und 100 ns Reaktionszeit und ist damit viel langsamer als der Cache.
Typische Spiele haben zwei Eigenarten, die Anwendungen meist nicht haben.
1. Chronologie und Synchronisation sind wichtig.
2. Es passieren die verschiedensten Dinge und das schwer vorhersagbar.
Ein CPU-Render-Benchmark wie Cinebench macht für jeden CPU Thread einen Programm Thread auf und gibt ihm eine Kachel des Bildes zum bearbeiten. Der Thread hat dann einen eingeschränkten Satz an Daten die er für die Berechnung baucht und die meist im L2 Cache Platz finden und muss sich mit keinem anderen Thread abstimmen. Er kann ungestört bis zum Ende rechnen...gibt das Ergebnis ab und fertig....es können fast beliebig viele CPU Threads mit Arbeit versorgt werden.
Eine Tabellenkalkulation/Datenverarbeitung hat mit abertausenden Einträgen und Berechnungen ebenfalls viel Arbeit für die CPU, aber es ist einfach vorherzusehen, was als nächstes an Daten benötigt wird.
Wenn ein CPU Kern die Aufgabe bekommt C[0] = A[0] + B[0] zu berechnen und dafür bei der Speicherverwaltung A[0] und B[0] anfragt, dann geht diese hin und fragt vom Arbeitsspeicher z.B. direkt A[0-63] und B[0-63] an. Für die erste Berechnung muss dann zwar z.B. 80 ns gewartet werden, bis es losgehen kann, aber mit großer Wahrscheinlichkeit ist die nächte Berechnung C[1] = A[1] + B[1] und die übernächste C[2] = A[2] + B[2]....deren Daten liegen jetzt schon im L1 Cache und die CPU kann ohne Wartezeit weiter rechnen.
Das ist jetzt der simpelste Fall für die Sprungvorhersage und diese kann noch deutlich kompliziertere Vorhersagen machen um den L1 Cache mit Daten zu füllen, bevor diese benötigt werden....es sollte aber als Beispiel genügen um zu zeigen, warum der L3 Cache in Anwendungen meist gar nicht benötigt wird und auch die Arbeitsspeicher Geschwindigkeit selten einen Einfluss hat.
Im Kontext von Spielen scheitert sowohl die Aufteilung auf beliebig viele CPU Threads, als auch die Sprungvorhersage, die Daten vorsorglich in den L1 Cache platziert.
Natürlich werden auch hier möglichst viele Arbeiten auf neue Threads aufgeteilt, aber das sind selten große zusammenhängende Berechnungen, die lange dauern und unabhängig sind. Stattdessen sind es eher kleine Aufgaben, bei denen das Erzeugen und Zusammenführen des neuen Threads einen entscheidenden Teil der Berechnungszeit ausmacht. Die Threads müssen immer wieder zusammengeführt werden, um das Spiel synchron und chronologisch zu halten. Viele Variablen werden von verschiedensten Funktionen verwendet und vor jeder Änderung muss die Variable für alle anderen Threads gesperrt werden und danach wieder freigeben werden. Das erfordert viel "core to core Kommunikation" und macht noch mehr Programm Threads, die noch öfter Variablen schreiben, immer ineffizienter.
Es werden verschiedenste Aufgaben bunt durcheinander gewürfelt...von KI-Entscheidungen, Lebenspunkten, Kämpfen, Wegfindung, usw. bis zu Drawcalls um die GPU zu füttern.
Das macht es für die Sprungvorhersage extrem schwer und es gibt viel viel mehr zeitkritische Arbeitsspeicherzugriffe.
Ein großer L3 Cache vergrößert die Chance, dass diese zufälligen Arbeitsspeicher Zugriffe abgefangen werden können und die CPU Pipeline z.B. nur 9 statt 90 ns stillsteht.
In Summe kann das dann z.B. auch 50-70% mehr FPS im CPU Limit bedeuten....oder nur 10%....oder auch gar kein Vorteil, wobei dass dann schon ein sehr spezielles Spiel sein müsste, dass durch eine spezielle Berechnung limitiert ist...und diese Berechnung perfekt vorhergesagt werden kann...gleicher Takt und Architektur vorausgesetzt.
