AW: "CPU-Tests in 1.280 × 720 sind falsch!" - stimmt, optimal wären Tests in 16 × 9 Pixel - Ein Kommentar
Thema leider nur sehr oberflächlich angekratzt. Die Sache ist in Wahrheit ein wenig komplizierter: Normalerweise würde man sagen, dass man im CPU-Limit testet, um die Eignung für kommende Spiele zu testen - gemäß der Annahme, dass der Prozessor, der schneller "ins Limit" geht, das auch bei höherer Belastung tut.
Das Problem an der Geschichte ist, dass in vielen Fällen völlig unklar ist, was da eigentlich getestet wird, denn "die Prozessorleistung" in dem Sinne gibt es nicht. Wenn die eine CPU bei Counter Strike 400 fps schafft, die andere aber nur 350 fps, dann limitieren vermutlich längst Faktoren, die überhaupt nicht linear skalieren - das könnten zB die Cache-Architektur sein, oder das Verschieben von Daten zwischen den Kernen oder weiß der Geier was.
Das Problem ist jetzt, dass sich der Einfluss dieser Faktoren eben prinzipiell nicht auf eine Situation übertragen lässt, in der die CPU stärker gefordert wird. Du kannst also überhaupt nur dann von einem 720p-Test in die Zukunft extrapolieren, wenn die CPU dabei trotzdem so gefordert wird, dass die fps in "normalen" Bereichen liegen.
AMD benutzt zur Verbindung zwischen den Kernen ein Mesh mit dem klangvollen PR-Namen "Infinity Fabric". Intel benutzt einen Ringbus, um die Kerne miteinander zu verbinden.
Uns braucht jetzt erstmal nicht zu interessieren, wie genau die beiden Ansätze funktionieren, nur das folgende ist interessant: Die beiden Ansätze skalieren unterschiedlich in Hinsicht auf Bandbreite und Latenz, wenn man die Zahl der Kerne erhöht.
Das führt zu folgendem Phänomen: Der Ringbus hat eine geringere Latenz als das Mesh... bis man die Zahl der Kerne nach oben schraubt. Für den Intel 9900k zum Beispiel reicht der Ringbus noch dicke aus, aber ganz sicher nicht mehr für die dicken Server-Prozessoren mit ihren >24 Kernen. Deshalb hat Intel in der Server-Linie auch ebenfalls auf ein Mesh gesetzt; nur die Gaming-CPUs haben noch den Ringbus. AMD hat sich das aus Kostengründen gespart, die setzen bei allen Linien auf die gleiche Lösung.
Der Witz ist jetzt aber, dass Latenzen dieser Art nicht wirklich mit der Belastung durch Spiele skalieren. Nehmen wir an - Vorsicht, Zahlen allesamt aus dem Stegreif ausgedacht -, dass die Grafikkarte 3 ms braucht, um ein Frame zu rendern, die CPU aber 5 ms. Dann bekomme ich am Ende zwar 200 fps raus (und die Grafikkarte langweilt sich), aber *ich weiß nicht, wo die 5 ms genau herkommen*.
Nehmen wir weiter an, dass Latenzen wie vom Ringbus/Mesh in genau diesem Fall hauptverantwortlich für die 5 ms sind. Dann bedeutet das, dass die Frametimes in diesem Spiel niemals unter 5 ms fallen können - aber auch, dass diese Latenzen in Zukunft nicht maßgeblich höher sein werden. Ich laufe also in eine Art systemspezifisches Limit hinein, das sich niemals ändern wird - die eine CPU wird dann halt immer X ms Latenz in einem gegebenen Fall haben und die andere Y ms.
Diese X/Y ms verschwinden aber komplett von der Bildfläche, sobald ein anderer Faktor - zum Beispiel eine höhere Belastung der CPU - dafür sorgt, dass die Frametimes länger werden als X respektive Y. Die Latenz bleibt zwar da, aber es kann gut sein, dass sie in den "herkömmlichen" Framebereichen zwischen 60 und 120 fps einfach keine Rolle spielt, und zwar unabhängig von der sonstigen Beanspruchung der CPU.
Noch wesentlich lustiger wird es, wenn man sich überlegt, dass der Unterschied zwischen Ringbus und Mesh nur eine von vielen möglichen Quellen solcher "Obergrenzen" sein können. Treiberoverhead wäre noch so ein Faktor, oder (da AMD Chiplets à 4 CPU-Kernen verbaut) wie es mit dem Verschieben von Daten zwischen einzelnen Kernen vs. dem Verschieben von Daten zwischen den Chiplets aussieht.
