TEST

Intel Core Ultra 200S alias Arrow Lake im Test

Der Pfeil findet sein Ziel nicht immer - Sondertests: Latenzen

Portrait des Authors


Werbung

Wie immer wollen wir auch einige Sonders-Tests präsentieren. Als Chiplet-Design gibt es hier einige Herausforderungen, denen Intel begegnen musste. Ein wichtiger Punkt spielen dabei die Kern-Latenzen. Bei einem monolithischen Design spielen diese allenfalls in den einzelnen Clustern eine Rolle.

Bei den Core-Prozessoren der 13. und 14. Generation lagen die Kern-Latenzen im Bereich von 40 bis 50 ns. Eine größere Rolle aber spielten sie bei Meteor Lake, denn hier gibt es ein dreistufiges Design: Performance- und E-Kerne in einem Cluster sowie zusätzlich zwei Low-Power-Efficiency-Kerne im SoC-Chiplet. Die Performance- und Efficiency-Kerne sitzen auf dem Compute-Chiplet in einem Cluster. Die LPE-Kerne aber eben auf einem gesonderten Chiplet, dem SoC-Chiplet, was zusätzliche Implikationen für die Latenzen hat.

Arrow Lake besitzt genau wie Lunar Lake ein zweistufiges Kern-Design, wie wir es auch schon von Alder Lake und Raptor Lake kennen. Es gibt Performance-Kerne und Efficiency-Kerne – jeweils in einem eigenen Cluster organisiert und mittels NOC-Interconnect (Network on Chip) miteinander verbunden.

Zwischen den P- und E-Kernen in Lunar Lake sowie bei den P-, E- und LPE-Kernen bei Meteor Lake waren größere Unterschiede erkennbar. Für die Core-Ultra-200S-Prozessoren sehen die Latenzen wie folgt aus:

Bis zu acht Performance-Kerne und vier Efficiency-Kern-Cluster finden sich in den Prozessoren und gerade diese Cluster sind auf den Latenzmessungen noch zu erkennen. Beim Core Ultra 5 245K sind es derer zwei, die sich in der Diagonalen finden. Beim Core Ultra 7 265K sind es drei und beim Core Ultra 9 285K drei. Allerdings kann Intel innerhalb des Compute-Tiles die Latenzen noch einmal reduzieren. Von anfangs erwähnten 40 bis 50 ns auf nun 20 bis 40 ns.

Zumindest für das Compute-Tile sind die Kern-Latenzen also weiterhin unproblematisch. Wie aber schaut es im Chiplet-Design mit den Latenzen aus, wenn Daten aus dem Compute-Tile in den SoC-Tile übertragen werden, damit sie über den Speichercontroller in den DDR5 übertragen werden?

Cache- und Speicherbandbreite sowie Latenzen

Anwendungen wie Spiele laufen aber natürlich nicht nur auf dem Compute-Tile. Daten müssen aus dem Arbeitsspeicher zum Speichercontroller im SoC-Tile übertragen werden. Von dort geht es in den Compute-Tile mit den CPU-Kernen und diese wiederum kommunizieren über einen Interconnect mit dem PCI-Express-Controller, die sich im Compute- und SoC-Tile befinden. Die Kommunikation zwischen den Tiles und über das Package hinaus ist somit von hoher Bedeutung.

Für den Core Ultra 9 285K messen wir eine maximale Lese- und Schreibtransferrate von 6,5 bzw. 4,8 TB/s, wenn alle Threads verwendet werden. Bei Nutzung nur eines Threads sind es 226 bzw. 120 GB/s. Bei den Ryzen-9000-Prozessoren sind es 730 GB/s für das Lesen und 325 GB/s für das Schreiben mit einem Thread. Für den Ryzen 9 9950X mit 24 Threads kommt das AMD-Package (siehe unsere Analyse) auf 10 TB/s für das Lesen und 5,2 TB/s für das Schreiben von Daten. Zumindest in der Bandbreite ist AMDs Infinity Fabric der Lösung von Intel also offenbar überlegen.

Für die Latenzen sieht man recht deutlich, bis zu welcher Kapazität die Testdaten noch in den L0-, L1- und L2-Cache passen. In diesen Stufen sehen wir noch niedrige Latenzen im Bereich von maximal 12 ns. Müssen die Daten dann im L3/LLC-Cache abgelegt werden, sprechen wir von 32 ns und geht es in den Arbeitsspeicher, legen die Latenzen für DDR5-5600 bei 100 ns und mehr.