Intel Core i7 "Nehalem" im Test - des Kaisers neue Kleider

Prozessoren | HT4U.net | Seite 5

Core i7-Technik: der Core-Bereich



Im Front-End jedes Prozessorkerns ergaben sich nur wenige Änderungen verglichen zum Core-Design. Die drei simple und eine complex Decoding Unit mit Macro-Op Fusion kann nach wie vor bis zu 4+1 Instruktionen in die Pipeline schieben. Allerdings kann Nehalem im Gegensatz zum Vorgänger auch 64 Bit-Instruktionen und mehr Instruktionen als früher mit Macro-Op Fusion verbinden, was in Hinblick auf Zukunftsfähigkeit sicher sinnvoll ist.

Die Erkennung von Schleifen in der Ausführung von abzuarbeitendem Programmcode wurde gegenüber dem Core-Design erweitert. Der Loop-Stream-Detektor, der mehrere (28 in der Nehalem-Form Bloomfield) in einer Schleife immer wieder ausgeführte Kommandos vorhalten kann, so dass kein Nachladen aus der Pipeline, Sprungvorhersage oder Cache-Abrufe dafür notwendig ist, wanderte in der Pipeline weiter nach hinten. Er liegt nun nach der Decode-Stufe statt nach der Fetch-Stufe, womit noch mehr übersprungen werden kann und Micro-Ops statt x86-Befehle bereitstehen, die schneller verarbeitet werden können. Da Nehalem vier Decoder besitzt, ist dieser Weg effizienter als der ähnliche Trace-Cache der Netburst-Architektur.

Bild: Intel Core i7

Ebenfalls ein von Generation zu Generation wiederkehrendes Mantra ist die Aussage, dass man die Sprungvorhersage verbessert hat. Speziell in hoch parallelisierten Systemen wie hier mit acht parallelen Threads ist die Sprungvorhersage wichtig, da eine unvorhergesehene Verzweigung im Rechenprozess Verzögerungen bedeutet, bis das Ergebnis berechnet ist, das zur Weiterarbeit benötigt wird. Intel setzte beim Bloomfield Core i7 eine zweite Stufe der Sprungvorhersage auf den Branch Predictor der Core-Architektur auf.

Diese Stufe ist langsamer, aber kann mehr Daten speichern, was v.a. bei Software mit nicht näher spezifiziertem „großem code footprint“ von Vorteil sein soll. Dies geht Hand in Hand mit dem größeren Return Stack Buffer, der die Sprungmarken speichert, von denen aus andere Funktionen aufgerufen wurden.

Weitere Modifikationen gibt es beim Translation Lookaside Buffer (TLB), der v.a. durch AMDs Bug in den Barcelona-Prozessoren bekannt wurde. Der TLB hält eine Tabelle vor, die virtuelle Speicheradressen von Anwendungen physikalischen Speicheradressen aus dem Hauptspeicher bzw. dem ausgelagerten Speicher zuordnet. Nehalem übernahm das zweistufige TLB-Konzept der Core-Architektur, allerdings stehen in der ersten Stufe nun für Instruktionen 128 Einträge für 4k-Pages und 7 2M/4M-Pages (pro Thread) zur Verfügung. Bei den Daten sind es 64 respektive 32 Einträge. Dem gegenüber hatte die Core-Architektur lediglich 16 Einträge für alles. In der zweiten Stufe stehen 512 Einträge zur Verfügung, doppelt so viele wie bisher. Während der L1-Daten- und der L2-TLB dynamisch zwischen Threads aufgeteilt werden können, ist der L1-Instruction-TLB statisch aufgeteilt.

Bild: Intel Core i7

In Nehalem beseitigt Intel einen Hemmschuh bei den Cache-Accesses. Die maximale Performance erreichte ein Zugriff auf eine Speicherseite nur, wenn die Daten der Größe einer 64 Byte Cacheline entsprach, ein sog. aligned Memory Access. Unaligned Memory Accesses erforderten mehr Aufwand, u.a. aufgrund der Tatsache, dass der Decoder mehrere µOps dafür erzeugen musste, die entsprechend auch abgearbeitet werden mussten. Tragischerweise sind auch viele eigentlich aligned vorliegende Zugriffe vom Compiler als Unaligned gekennzeichnet, in erster Linie aus Programmstabilitätsgründen.

Erkennt Nehalem nun einen unaligned access, der in Wirklichkeit ein aligned access ist, entfällt der Geschwindigkeitsnachteil. Für alle anderen Fälle implementierte das Design-Team nach eigener Aussage nicht näher spezifizierte Optimierungen.

Als letzte nennenswerte Optimierung ist der Prefetcher zu nennen. Schon in der Core-Architektur war diese Einheit, die spekulativ potenziell notwendige Daten aus dem Hauptspeicher in den Cache lud, wenn der Bus gerade frei war, ein Glanzstück des Designs, da es den potenziellen Flaschenhals FSB entschärfte. Allerdings kam sich der Prefetcher jeder CPU in Mehrprozessorsystemen, die über den gleichen FSB kommunizieren mussten, des Öfteren in die Quere, speziell bei speicherlastigen und kaum vorhersagbaren Serveranwendungen wie Datenbanken, so dass Intel zähneknirschend eine Funktion bereitstellen musste, um den gesamten Prefetch-Prozess abzuschalten.

Der zweistufige Prefetcher in Nehalem soll in diesem Punkt verbessert sein, allerdings nennt Intel keine Details dazu, wie. Allerdings kommt hier der integrierte Speichercontroller jeder CPU entgegen, der eine genaue Übersicht darüber hat, welcher Prozessor Zugriff auf den lokalen Speicher anfordert und den Prefetcher damit mit Bedacht einsetzen kann, um Konkurrenz auszuschließen.

 

Inhalt dieses Testberichtes