Prinzipiell gibt es neben der IPC nur noch einen Faktor: Den Takt. Beides mit einander multipliziert ergibt die Absolutleistung beziehungsweise letztlich ist die IPC nichts weiter als ein abgeleiteter Faktor, Absolutleistung durch Takt. Allerdings gibt es außerhalb der eigentlichen Rechenleistung der Kerne viele Faktoren (L2- und L3-Cache-Größe und -Latenz, Speichergeschwindigkeit und -Latenz, Latenz der Kern-Kern-Kommunikation sowie Befehlssätze wären die in den letzten Jahren wichtigsten Punkte), die die Leistung (und damit IPC) je nach Anwendung unterschiedlich beeinflussen. Um 15 Prozent mehr Spieleleistung zu erreichen, sind also möglicherweise andere Maßnahmen nötig, als um "15 Prozent mehr IPC" in einem Computer-Benchmark zu verzeichnen. Insbesondere Speicher- und Rechengeschwindigkeit stehen für unterschiedliche Anwendungen in einem komplett unterschiedlichen Verhältnis zueinander.
Nein. Die reine Laufzeit der Befehle ergibt nicht die IPC. Letztere wird für gewöhnlich über die Praxisleistung in der jeweiligen Anwendung ermittelt und umfasst dann auch etwaige Flaschenhälse (oder deren Fehlen) im Speichersystem.
Die Zusammenlegung der CCX sollte die RAM-Latenzen nicht beeinflussen und die L3-Latenz dürfte sogar steigen. Bei dieser Maßnahme wird vor allem die Latenz zwischen den Kernen reduziert, was aber auch bitter nötig ist. Zwischen CCX liegen die Zugriffszeiten bislang beim Vierfachen des Comet-Lake-Worst-Case.
SMT ist heute nicht so viel besser als zu Pentium-4-Zeiten. Aber der Nutzen hing und hängt immer davon ab, wie gut ein CPU-Kern durch einen einzelnen Thread ausgelastet wird und wie viele dieser Threads auf wie viele physische CPU-Kerne treffen. Praxisanwendungen, die mehr als 16 Kerne sinnvoll nutzen können, kann man meist an einer Hand abzählen. Oft genug auch an keiner Hand, weil es sie im Endverbrauchersegment kaum gibt. Vereinzelte Effekte, dass man wenige Prozent Performance gewinnt, wenn ein 17ter Thread nicht warten muss, lassen sich dann auch oft erzielen, wenn dieser mittels SMT mal schnell nebenbei berechnet wird. In den letzten Jahren wurde dieser Effekt in Spielen aber meist schon zwischen 8 und 16 Threads beobachtet. Ein Sechskerner mit SMT lieferte nicht selten bessere Ergebnisse als ein Achtkerner ohne, weil so viele leistungsfordernde, unabhängige Aufgaben einfach nicht zur Bearbeitung anstanden. Und ab 12 Kernen kann es weiterhin vorkommen, dass eine Deaktivierung von SMT das System in Spielen beschleunigt, weil der zusätzliche Verwaltungsaufwand für 24 logische Kerne mehr Rechenzeit kostet als durch SMT zusätzlich genutzt wird.
Ähnlich ambivalent ist Cache: Bis zu einer gewissen Größe kann es die Rechenleistung beinahe linear steigen, wenn Programmteile nicht mehr aus dem langsamen RAM nachgeladen werden müssen. Aber wenn bereits der gesamte Programmcode in den Cache passt und nur noch die einmalig zu bearbeitenden Daten geladen werden, dann bringt zusätzlicher Cache praktisch gar nichts mehr. Über mehrere Anwendungen und Szenarien hinweg, bei denen die Grenze jeweils anders liegt, ergibt sich dann ein abnehmender Grenzertrag. Zen2 ist hier sicherlich schon sehr extrem unterwegs, nutzt den Cache aber auch zum Ausgleich der langsamen Kern-zu-Kern-Kommunikation.
