Nehalem für alle - Intel Core i5 und Core i7 auf Sockel 1156 im Test

Prozessoren | HT4U.net | Seite 5

Der Core-Bereich: Technik



Wie bereits erwähnt, führte Intel mit der Nehalem-Architektur eine logische Teilung des Prozessors in Core- und Uncore-Bereiche ein. Während im Core-Bereich lediglich die zwei, vier oder sechs (Gulftown, erwartet 2010) Rechenkerne untergebracht sind, findet sich im Uncore der komplette Rest des Prozessors. Ersterer bringt dabei bei den Lynnfield-Modellen keine Neuerungen – von anderen Taktraten einmal abgesehen – mit. Dennoch wollen wir an dieser Stelle noch einmal kurz auf den Aufbau eines Prozessorskerns der Nehalem-Architektur eingehen bevor wir uns an die Neuerungen des Lynnfields wagen.

Der wohl auffälligste Unterschied zwischen den Nehalem-Prozessoren und den Core-2-Vorgängern ist neben der wiedereingeführten Unterstützung von Hyperthreading sicherlich die Veränderung im Cache-Design. Da es sich bei aktuellen Modellen auf Basis der Nehalem-Architektur um native Vierkern-Prozessoren handelt besitzen diese – anders als beispielsweise die Core 2 Quads – keinen von allen Kernen gemeinsam genutzen L2-Cache. Stattdessen besitzt jeder Kern seinen eigenen privaten 256 Kilobyte großen L2-Cache, welcher dann die unverändert 32 Kilobyte großen L1-Caches für Daten bzw. Instruktionen mit den nötigen Operanden speist.

CacheLynnfield Yorkfield
GrößeLatenzGrößeLatenz
L164 KB2 Zyklen64 KB3 Zyklen
L2256 KB8 Zyklenbis zu 2*6 MB13 Zyklen
L38 MB39 Zyklen--
RAM> 100 Zyklen> 100 Zyklen

Der relativ kleine L2-Cache gepaart mit dem sehr großen L3-Cache hat dabei nicht immer nur Vorteile gegenüber den Core-2-Prozessoren, denn die Wahrscheinlichkeit, dass Daten im nur unwesentlich langsameren L2-Cache der Core-2-CPUs liegen, ist wesentlich größer als die Wahrscheinlichkeit, dass sie im L2-Cache einer Nehalem-CPU liegen. Wenn sie aber nicht dort zu finden sind, muss der Prozessor erst den L3-Cache überprüfen bevor die Daten aus dem Hauptspeicher geladen werden. Es kann – und wird – also Situationen geben, in denen sich die Cache-Architektur des Nehalem zu einer Bremse gegenüber den Core-2-Modellen entwickelt.

Apropos Cache, erkennt ein Nehalem-Prozessor einen Zugriff auf eine Speicherseite, deren Daten so gekennzeichnet sind, dass deren Größe nicht einer 64-Byte-Cacheline entsprechen (unaligned memory access), obwohl dem nicht so ist (aligned memory access), so umgeht der Prozessor die für Unaligned-Zugriffe nötigen zusätzlichen Schritte und beschleunigt damit den Datenzugriff.

Sieht man einmal von diesen Änderungen ab, bietet die Nehalem-Architektur nur recht wenige handfeste Neuerungen gegenüber jener der Core-2-Prozessoren. Die Anzahl der SSE- sowie der andern Ausführungseinheiten hat Intel beispielsweise komplett übernommen. Auch im Front-End der Kerne gibt es noch immer die drei simple sowie eine complex Decoding Unit mit Macro-Op Fusion, die unverändert bis zu 4+1 Instruktionen in die Pipeline schieben können. Diese hat Intel allerdings um zwei Stufen auf nun 16 verlängert, was in der Theorie höheren Taktraten zuträglich ist.

Bild: Nehalem für alle - Intel Core i5 und Core i7 auf Sockel 1156 im Test

Dem Translation Lookaside Buffer (TLB), welcher vor allem durch den Bug in AMDs Barcelona-Prozessoren berühmt wurde, hat Intel ebenfalls ein paar Verbesserungen beschehrt. Der TLB dient dazu, mit Hilfe einer Tabelle die Übersetzung von der virtuellen Speicheradresse einer Anwendung in eine physikalische Adresse des Hauptspeichers bzw. dem ausgelagerten Speicher zu beschleunigen. Nehalem übernimmt dabei das zweistufige TLB-Konzept der Core-Architektur, wobei die Tabellen nun deutlich größer ausfallen. So fasst die erste Stufe nun 128 Instruktions-Einträge für 4k-Pages und 7 von 2M/4M-Pages. Bei den Daten sind es immerhin noch üppige 64 bzw. 32 Einträge. Zum Vergleich, die Core-Architektur muss mit 16 Einträgen für alles auskommen. Die zweite Stufe ist nun mit 512 Einträgen doppelt so groß wie beim Vorgänger. Da das Umrechnen der Adressen eine relative langwierige Prozedur sein kann, hilft ein großer TLB ungemein.

Auch dem Prefetcher sind einige Optimierungen zu gute gekommen. Dieser dient dazu Befehle und Daten bereits für die Ausführung vorzubereiten, in dem er beispielsweise spekulativ potenziell notwendige Daten aus dem Hauptspeicher in den Cache lädt, um damit die anschließende Bearbeitung zu beschleunigen. Bereits beim Core-Design war der Prefetcher ein Glanzlicht, entschärte er doch den potentiellen Flaschenhals FSB. Gerade in Mehrprozessor-Systemen, wie sie im Serverbereich an der Tagesordnung sind, trat jedoch häufiger die Situation ein, dass sich die Prefetcher gegenseitig behinderten. Dies will Intel beim Prefetcher des Nehalem verhindern, wobei man Genaueres dazu nicht erwähnt.

Bild: Nehalem für alle - Intel Core i5 und Core i7 auf Sockel 1156 im Test

Ebenfalls die Erkennung von Schleifen in der Auführung von aktiven Programmen ist gegenüber dem Core-Design verbessert worden. Der Loop-Stream-Detektor merkt sich dabei 28 Befehle, welche in einer Schleife immer wiederholt werden, so dass während der Ausführung kein Nachladen aus der Pipeline nötig wird. Auch die Sprungvorhersage – die man mit Nehalem noch einmal deutlich verbessert hat – ist somit in diesen Fällen nicht mehr notwendig. Da Intel den Detektor nun zudem hinter die Dekodier-Stufe verschiebt, beschleunigt sich die Abarbeitung von Schleifen nochmals, da nun Micro-Ops statt x86-Befehlen bereitstehen, welche schneller verarbeitet werden können.

Neben den hier genannten Änderungen gibt es natürlich noch einige andere, doch würde deren Nennung und Erklärung den Rahmen des heutigen Tests sprengen, weshalb wir uns auf diese beschränken wollen.