AMD vs. Intel. - Ausarbeitung zur Präsentation - Hochschule Bremen Fachbereich Elektrotechnik und Informatik. Studiengang Technische Informatik

Transkript

1 AMD vs. Intel - Ausarbeitung zur Präsentation - Hochschule Bremen Fachbereich Elektrotechnik und Informatik Studiengang Technische Informatik Rechnerstrukturen, Labor (RST-L) Prof. Dr. Thomas Risse Wintersemester 2007/ 08 Vorgelegt von: Christoph Bartels, Christian Dinter, Martin Lange, , Bremen

2 Inhaltsverzeichnis Inhaltsverzeichnis Einführung Firmenbeschreibung (AMD) Firmenbeschreibung (Intel) Architekturbeschreibung Beschreibung der K8 Architektur Ausblick auf die K10 Architektur Core-Beschreibung Ausblick auf die neue Core-Generation (Penrym) Hauptspeicher (RAM)- und Chipsatz-Anbindung Speicher-Adressierung / -Verwaltung AMD K8 (Athlon 64 X2) Intel Core (Core 2 Duo) Gegenüberstellung Cache und TLBs Level 2 Cache Gegenüberstellung Level 2 Cache Level 1 Cache Translation Lookaside Buffers (TLBs) Prefetching AMD K8 (Athlon 64 X2) Intel Core (Core 2 Duo) Benchmarks CPU-Performance: SPEC CPU Speicher: Sciencemark Analyse: SunGard ACR Rendering: 3ds Max System-Performance: BAPCo Sysmark 2004 SE Energieverbrauch Ausblick in die Zukunft Resümee Quellenverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Bartels, Dinter, Lange Seite 2 von 43

3 1. Einführung Diese Ausarbeitung vergleicht den Aufbau und im Besonderen die Speichertechnologien (Anbindung und Schnittstellenaufbau) der jeweils aktuellen Mikroprozessorarchitektur von Intel und AMD. Die beiden miteinander konkurrierenden Architekturen sind in diesem Fall die K8-Architektur von AMD und die Core-Architektur von Intel. Diese Dokumentation gliedert sich in mehrere Teile, zunächst werden die beiden Kontrahenten vorgestellt und der wesentliche Aufbau der beiden Mikroprozessorarchitekturen erklärt, um die anschließende Detailerklärung der Speicheranbindung und -technologie einordnen zu können. Außerdem wird auf die Änderungen der nachfolgenden Architekturen bzw. Versionen eingegangen. Den Abschluss bilden einige Benchmarks, die deutlich machen, welche Vor- und Nachteile die verschiedenen Ansätze mit sich bringen Firmenbeschreibung (AMD) Die Firma AMD (Advanced Micro Devices) wurde im Jahre 1969 gegründet und produzierte zunächst Schieberegister, Speicherbausteine und Mikroprozessoren erwarb AMD eine Lizenz von Intel zur Herstellung von und 8088-Prozessoren. Infolgedessen produzierte AMD eigene Nachbauten von Intel-Entwicklungen, so wurde beispielsweise ein Nachbau als Am286 von AMD vertrieben. [vgl. AMD08, AMD07] Im Jahre 1986 kündigte Intel den Vertrag, der diese Praxis erlaubte und AMD reagierte mit einer Klage, aus der sich ein Rechtsstreit um die Lizensierung von Prozessormodellen entwickelte. Aufgrund des schwebenden Verfahrens konnte AMD noch und Modelle entwickeln und war erst nach Jahren in der Situation, eine eigene Prozessorlinie produzieren zu können. [vgl. AMD08, AMD07] Diese erste eigene moderne Mikroarchitektur war der K5, diese konnte allerdings erst 1996 vorgestellt werden, da die Entwicklung einer Mikroarchitektur einiges an Ressourcen und Zeit kostet. So war der K5 aufgrund der späten Markteinführung nie eine echte Konkurrenz für den Intel Pentium. Erst der Nachfolger, die K6 Architektur (1997), brachte AMD einen Riesensprung nach vorn im Rennen um den schnellsten x86 Prozessor. Diese neue Architektur basierte auf einem Model der kurz zuvor übernommenen Firma NexGen, diese wurde zunächst um die MMX Befehle und in einem nächsten Entwicklungsschritt (K6-2, 1998) um die eigene SIMD Erweiterung 3Dnow! erweitert. [vgl. AMD08, AMD07] 1999 wurde eine weitere Variante des K6 entwickelt, der K6-III. Dieser bestand eigentlich nur aus einem K6-2 mit einem integrierten 256KB L2-Cache. Zwar brachte dies einen großen Geschwindigkeitsvorteil, jedoch wurde der Die extrem groß und somit sehr teuer in der Fertigung. Der letzte Nachfolger als K6 basiert eben aus diesem Grund wieder auf dem K6-2 und wurde K6-2+ genannt, dieser wurde bereits in 0,18µm gefertigt. [vgl. AMD08, AMD07] Der Nachfolger des K6 wurde der K7, dieser war erstmals dem Konkurrenten, Intels Pentium III technisch überlegen und so konnte AMD den ersten x86-prozessor veröffentlichen der die 1GHz Marke durchbrach. Möglich wurde dies auch durch die neuen Fabriken in Dresden, denn hier konnte erstmals ein AMD Prozessor ohne grössere Fertigungsprobleme gebaut werden. [vgl. AMD08, AMD07] Bartels, Dinter, Lange Seite 3 von 43

4 Schließlich wurde 2003 der K8 veröffentlicht. Mit dieser neuen Architektur stellte AMD die erste vor, die mit einer 64Bit Technologie arbeitet. Diese Architektur wird, in der neusten Ausprägung, in dieser Ausarbeitung näher vorgestellt und mit Intels Core-Architektur verglichen. [vgl. AMD08, AMD07] 1.2. Firmenbeschreibung (Intel) Die Intel Corporation, 1968 gegründet, konzentrierte sich bis Anfang der 80er Jahre zunächst auf den Markt der Speichertechnologien. Zwar entwickelte Intel bereits 1974 den 8080, einen der ersten vollwertigen Mikroprozessor; der Speichermarkt, insbesondere DRAM, blieb jedoch bis zu einem starken Umsatzeinbruch um 1983 das Kerngeschäft. [vgl. INT08, INT07d] Hiernach wurden die Mikroprozessoren zu dem Standbein des Konzerns. Hier sticht insbesondere die x86er Prozessorfamilie hervor, die durch eine geschickte Lizenz und Markenpolitik zu einer der am weitesten verbreiteten Prozessorfamilien der Welt gehört und Intel eine marktbeherrschende Stellung im PC-Prozessoren-Sektor verschaffte. Zwar wurden die x86 Prozessoren im Wesentlichen von Intel entwickelt, jedoch auch von AMD vertrieben. Dies wurde ermöglicht durch eine von Intel vergebene Lizenz, die 1986 gekündigt wurde. [vgl. INT08, INT07d] Wichtige Vertreter waren 1985 der i386dx, der erste 32Bit Prozessor der Reihe und 1989 die Weiterentwicklung i486dx mit integriertem L1-Cache und einem ebenfalls integriertem mathematischen Coprozessor (FPU). Die beiden Serien liefen lange parallel, da die Kosten für einen 486er Prozessor bis zu 6000 US-Dollar betrugen und diese somit nicht für Privatanwender erschwinglich waren. Im Laufe der Entwicklung wurden die Caches beider Reihen vergrößert und die Taktraten erhöht. [vgl. INT08, INT07d] Erst 1993 wurde mit dem Pentium eine grundlegend neue Architektur veröffentlicht. Diese gilt als erste, superskalare CISC-Architektur der Welt und verfügte über eine echte, parallel arbeitende, Pipeline. Trotz Startschwierigkeiten mit der 486er Konkurrenz im eigenen Haus hielt Intel an der jungen Architektur fest und entwickelte sie konsequent weiter. So folgte 1994 eine multiprozessorfähige Version und später der Pentium MMX. Letzterer verfügte als erster x86- Prozessor über eine SIMD-Erweiterung zur Verarbeitung großer Integerdatenmengen, wie sie bei Video/Audio oder Bild- Verarbeitung anfallen. [vgl. INT08, INT07d] Am Ende der Pentium-1 Reihe stand Intel bei einer Taktrate von 233MHz (Desktop) bzw. 300MHz (Mobil). Der nächste Entwicklungsschritt war der Pentium Pro (P6), er verfügt intern über 3 parallel arbeitende RISC Pipelines und unterscheidet sich somit deutlich von seinem Vorgänger, dem Pentium. Ein neues Konzept war zudem die Out-of-Order Ausführung von Befehlen, die eine effizientere Parallelisierung erlaubt. Trotz der deutlichen Leistungssteigung zum Pentium konnte sich der P6 nicht am Markt durchsetzen, da Intel Probleme mit der Fertigung des On-Chip-Caches hatte und daher den Preis nicht auf Marktniveau senken konnte. [vgl. INT08, INT07d] Trotz dieser Probleme wurde die P6 Architektur zur Grundlage aller Nachfolgemodelle der Pentium- Serien, allen voran dem Pentium II, der im Wesentlichen ein P6 mit getrenntem Cache und hinzugefügtem MMX-Modul war (maximaler Takt: 450MHz). Außerdem wurde parallel zum Pentium II ein Modell für den Low-Cost Sektor vermarktet, der Celeron. Dieser hatte die Einschränkungen eines reduzierten L2 Caches sowie eines niedrigeren FSB-Taktes. [vgl. INT08, INT07d] Bartels, Dinter, Lange Seite 4 von 43

5 Die nächste Generation hieß folgerichtig Pentium III und verfügte nun endlich über den On-Chip- Cache sowie über die SSE Einheit, mit der Gleitkommaberechnungen stark beschleunigt wurden. Außerdem plante Intel mit dieser Prozessorgeneration weltweit eindeutige und per Software auslesbare IDs zu vergeben, musste dieses Vorhaben nach massiven Protesten von Datenschützern jedoch wieder aufgeben. Die letzte Version des Pentium III lief mit einem Takt von 1133 MHz. [vgl. INT08, INT07d] Der Pentium 4 (Nov. 2000) arbeitete mit der NetBurst Architektur. Charakteristisch hierfür ist eine extrem lange Pipeline (bis zu 31 Stufen), die mit einen sehr hohen Takt (bis 4 GHz) arbeitet. Hierzu war es notwendig, die Sprungvorhersage zu verbessern und die einzelnen Stufen der Pipeline möglichst klein und einfach zu halten. Intel plante diese Architektur durch einen ansteigenden Takt längere Zeit betreiben zu können, jedoch machten Problem bei der Leistungsaufnahme und eine starke Wärmeerzeugung einen Strich durch diese Pläne. [vgl. INT08, INT07d] Abgelöst wurde die NetBurst Architektur auf dem Desktop-Sektor von der Core-Architektur, die wieder mehr auf dem Pentium III, also auf der P6 Architektur, als dem Pentium 4 basiert. In dieser Ausarbeitung wird die Core-Architektur näher beschrieben und mit AMDs letzter K8 Ausprägung verglichen. [vgl. INT08, INT07d] Bartels, Dinter, Lange Seite 5 von 43

6 2. Architekturbeschreibung Im folgenden Abschnitt werden die beiden konkurrierenden Architekturen näher beschrieben. Die dargestellten Schaublider zeigen Verarbeitungsblöcke, diese umfassen teilweise mehrere Pipelinestufen Beschreibung der K8 Architektur Die etwas ältere K8 Architektur von AMD hat ein an den Athlon (K7) angelehntes Design. Die interne Verarbeitung ähnelt hingegen der RISC Pipeline einer Alpha-CPU. Dies ist vermutlich auf den Chef- Entwickler zurückzuführen, der auch den Alpha entwarf. Mit den 12 Stufen für Integer- Berechnung und 17 Stufen für die Floating-Point-Berechnungen ist die Pipeline der K8-Architektur in etwa so lang wie die von Intels P6. Die K8 Architektur entspricht einem dreifach superskalaren Design. Zusätzlich zu dem klassischem Aufbau der Architektur verfügt der K8 in der neusten Version über eine Hardwareunterstützung für Virtualisierung, Pacifica genannt. [vgl. AMD05, AMD07, CT06c, FOG07] Die ersten Modelle der K8 Architektur wurden als Single-Core-CPUs verkauft, allerdings war die Architektur von Anfang an auf den Dual-Core-Betrieb ausgelegt. Die ersten Dual-Core-Modelle der K8 Architektur wurden ab 2005 verkauft. Dabei werden auf einem Die zwei Kerne integriert, die dann über den Cross Bar Switch (XBAR) kommunizieren. [vgl. AMD05, AMD07, CT06c, FOG07] Zunächst werden die x86 Befehle, die im L1 Instruction Cache liegen, in den Prefetch-Buffer, im Bild Fetch 2-transit, geladen. Das Besondere hieran liegt in der Konstruktion des L1 Caches, er speichert zusätzlich zu den reinen Instruktionen die sogenannten Predecoded Bits. Sie enthalten Informationen über Sprünge und die Länge der Instruktionen. Da dies nicht mehr aus der Instruktion generiert werden muss kann in der Pipeline Zeit gespart werden. Aus dem L1-Cache können bis zu 16 Bytes pro Takt zur Pipeline transportiert werden. [vgl. AMD05, AMD07, CT06c, FOG07] Aus dem Prefetch-Buffer gelangen die Instruktionen dann zu den drei Decodern, diese wandeln dann parallel drei x86-befehle in Mikrooperationen um. Nach der Umwandlung werden dann bis zu sechs der entstandenen Mikrooperationen von den Packern in drei MacroOps zusammengefasst. Diese MacroOps bestehen aus je zwei Befehlen, einem für die ALU und einem für die AGU. Sie gelangen dann in die 72 Einträge umfassende Instruction Control Unit (ICU). [vgl. AMD05, AMD07, CT06c, FOG07] Hier werden die logischen Register des x86 Befehlssatzes auf die physikalischen Register der K8- Architektur gelegt. Dies ist unter anderem deshalb nötig, weil so einige der Pseudo-Abhängigkeiten, die die Out-of-Order- Ausführung hemmen, aufgelöst werden können. Um dies auch gewährleisten zu können, sind mehr reale Register vorhanden, als der Befehlssatz vorsieht. Die Zuordnung geschieht in der ICU. Nach dem Auflösen der Abhängigkeiten werden die MacroOps an die drei Integer- und den Gleitkomma-Scheduler übergeben. [vgl. AMD05, AMD07, CT06c, FOG07] Bartels, Dinter, Lange Seite 6 von 43

7 In der folgenden Abbildung ist der grundlegende Aufbau der K8 Architektur dargestellt. Abbildung 1: K8 Architektur im Überblick [CT07c] Der oben beschriebene Aufbau der MacroOps erklärt sich, wenn man einen Blick auf die Konzeption der Scheduler für die Ausführungseinheiten betrachtet. Jeder der drei Integer Scheduler ist in der Lage, bis zu acht MacroOps zwischenzuspeichern und sie wieder in die einzelnen Operationen aufzutrennen. Die Integer-Scheduler verfügen je über zwei Ausführungseinheiten, die parallel arbeiten können. Die Gleitkomma-Schedulereinheit verfügt sogar über 36 Plätze und drei Ausführungseinheiten. Insgesamt wäre es also möglich neun Mikrooperationen (Sechs Integer- und drei Float-Operationen) parallel ausführen zu können. Dies gelingt sehr selten. Wenn es im Extremfall doch möglich ist würde die 3-fach skalare Pipeline leerlaufen und müsste neu gefüllt werden. Dies würde dazu führen das der Performancegewinn durch die schnelle Ausführung verloren geht. [vgl. AMD05, AMD07, CT06c, FOG07] Zusätzlich zu der Gleitkommaberechnung findet im FPU-Pfad auch die Ausführung der SSE Berechnung statt. Hier liegt auch der Grund, aus dem der Zwischenspeicher der FPU wesentlich grösser ist als der der Integer-Scheduler. Die K8-Architektur verfügt nur über einen 64 Bit breiten Bus, über den es nicht möglich ist, die teilweise 128-bitigen SSE-Operationen in einem Stück ausführen zu können. So müssen diese sogenannten Double-Dispatch-Operationen vorher von dem Bartels, Dinter, Lange Seite 7 von 43

8 FPU-Scheduler getrennt und anschließend hintereinander ausgeführt werden. Dies passiert jedoch nicht ausschließlich bei SSE-Befehlen sondern kann auch bei einigen Gleitkomma-Berechnungen oder Stack-Operationen notwendig werden. Dieses Vorgehen ermöglicht zwar die Ausführung solcher Befehle, hemmt aber die effiziente Ausnutzung der Pipeline, da die Double-Dispatch-Operationen zwei Ausführungsphasen im FPU-Zweig benötigen. [vgl. AMD05, AMD07, CT06c, FOG07] Nach der Adressberechnung in den AGU-Ausführungseinheiten können in der Load/Store Queue zwei, 64Bit Speicherzugriffe pro Takt ausgeführt werden. Die LSU (Load-Store-Unit) kann sowohl auf den L1-Datencache, den L2-Cache als auch den Hauptspeicher zugreifen. Für die Zugriffe auf den L1-Datencache stehen 12 Einträge, für den Zugriff auf den L2-Cache und den Hauptspeicher 32 Einträge in der Load/Store Queue zur Verfügung. Im Extremfall können also bis zu 11 Mikrooperationen (neun Mikrooperationen in den Ausführungseinheiten und zwei Load/Store Operationen in der LSU) parallel ausgeführt werden. [vgl. AMD05, AMD07, CT06c, FOG07] Eine weitere Besonderheit der K8-Architektur ist der Speichercontroller, der sich anders als bei Intels Core-Architektur, auf dem Die des Prozessors befindet, also in diesen integriert ist. Die Vor- und Nachteile dieser Lösung werden später in dieser Ausarbeitung ausführlich diskutiert. Dieser Speichercontroller verfügt einen Crossbar-Switch mit angeschlossenen drei Hyper-Transport-Links und einem Interfache für DDR2-Speicher. Der Crossbar-Switch ist außerdem auch bereits für die Synchronisierung mit einem zweiten CPU-Kern ausgelegt. [vgl. AMD05, AMD07, CT06c, FOG07] 2.2. Ausblick auf die K10 Architektur Der Nachfolger der K8 Architektur ist die K10 Architektur, die aktuellste von AMD. Wie im folgenden Schaubild zu erkennen ist, basiert sie stark auf ihrem Vorgänger, dem K8. Allerdings ist diese Architektur von Anfang an für den Vierkernbetrieb ausgelegt worden. Alle vier Kerne, die auf einem Die integriert sind, kommunizieren untereinander über die Cross Bar (XBAR). Der K10 wird direkt in AMDs neuer 65nm Technologie gefertigt. [vgl. AMD07c, CT07c, RWT07b, TR07] Möglich wird dieser Vierkernbetrieb durch den zusätzlichen Level 3 Cache der vorwiegend zum auflösen der Kohärenz verwendet wird. Dieser L3 Cache wird also unter allen vier Kernen geteilt. Um zusätzliche Performance aus der Architektur herauszuholen wurden viele der internen Busssysteme verbreitert. So wurde zum Beispiel der Bus in der SSE Einheit auf 128Bit verbreitert. Hier werden jetzt keine Double-Dispatch-Befehle mehr benötigt. Alle Befehle, bis 128Bit, können nun in einem Schritt verarbeitet werden. [vgl. AMD07c, CT07c, RWT07b, TR07] Außer den Bussen wurden auch die einzelnen Caches und Buffer vergrößert und die TLBs bekamen mehr Einträge. Als weiteres Feature wurde der SSE-Befehlssatz erweitert und zwar um ein Bündel von AMDspezifischen Befehlen. Diese SSE Version läuft unter der Bezeichnung SSE 4a. Einige der neuen Befehle benutzen eine neue Ausführungseinheit, die ABM. In dieser können Advanced Bit Manipulation - Befehle wie POPCNT oder LZCNT sehr effizient ausgeführt werden. POPCNT beispielsweise zählt die Anzahl der gesetzten Bits eines Maschinenwortes, LZCNT zählt die führenden Nullen. [vgl. AMD07c, CT07c, RWT07b, TR07] Bartels, Dinter, Lange Seite 8 von 43

9 Die K10 Architektur ist in der folgenden Abbildung dargestellt. Alle Änderungen zum K8 sind rot markiert. Abbildung 2: K10 Architektur im Überblick [CT07c] 2.3. Core-Beschreibung Der grobe Ablauf der Core Pipeline gleicht im Wesentlichen der im P6 und der Architektur für Mobile Prozessoren Yonah. Allerdings wurden sämtliche Busse verbreitert und an fast allen Stufen Verbesserungen vorgenommen. Das Zentrum der 14-stufigen Pipeline bildet die Reservation Station, die die Mikrooperationen an die Ausführungseinheiten verteilt. Die Core Architektur entspricht einem vierfach superskalaren Design. [vgl. CT06c, INT06, INT07d, INT07e, FOG07] Bartels, Dinter, Lange Seite 9 von 43

10 Bei der Core Architektur handelt es sich um eine vollwertige Dual-Core-Architektur. Die beiden Kerne, die auf einem Die integriert sind, kommunizieren untereinander über den gemeinsamen L2 Cache. Bei den Vier-Kern-Modellen der Core Architektur handelt es sich im Grunde um zwei Zwei- Kern-Prozessoren, die in einem Chip integriert wurden. Die Kommunikation zwischen diesen muss über den FSB (Front Side Bus) abgewickelt werden. [vgl. CT06c, INT06, INT07d, INT07e, FOG07] Die Core Architektur ist in der folgenden Abbildung dargestellt (siehe Abbildung 3). Abbildung 3: Core Architektur im Überblick [CT07c] Die x86-befehle werden aus dem Instruction Cache über einen 128Bit breiten Bus in einen kleinen Zwischenspeicher (Instruction Streaming Buffer, 32Byte) geladen. Die Datenrate zu den Decodern beträgt 16Bytes/Takt, also kann mindestens eine x86-instruktion von maximal 15Byte Länge geladen werden. Da die durchschnittliche Instruktionsgrösse innerhalb von Programmen 4Byte beträgt, können im Schnitt 4 Instruktionen pro Takt geladen werden. [vgl. CT06c, INT06, INT07d, INT07e, FOG07] Bartels, Dinter, Lange Seite 10 von 43

11 Die Sprungvorhersage ist schon im Frontend der Pipeline platziert, hier konkurrieren zwei verschiedene Verfahren um die bessere Vorhersage, ob gesprungen wird oder nicht; die mit der besseren Trefferrate wird bevorzugt. Außerdem werden spezielle Vorhersagetechniken für Schleifen und indirekte Sprünge verwendet. Zusätzlich dazu verfügt die Core-Architektur über einige Vorhersagetechniken für Stackpointerberechnungen. Diese frühe Vorhersage ist wichtig, da bei einem nicht vorhergesehenen Sprung die Pipeline gelöscht und von der Zieladresse an neu gefüllt werden müsste. Das kostet eine Menge Zeit, einen Takt pro Stufe. [vgl. CT06c, INT06, INT07d, INT07e, FOG07] Auch die neuentwickelte MacroOp-Fusion spart eine Menge Taktzyklen, sie kann in einem fünf Befehle umfassenden Fenster zwei präcodierte x86 Befehle zu einem verschmelzen. So kann ein Vergleichs- und ein darauffolgender Sprungbefehl als ein x86-befehl vom Complex Decoder in eine einzige Mikrooperation übersetzt werden. Diese Methode erlaubt es, theoretisch fünf x86-befehle mit nur vier Decodern zu decodieren. Allerdings ist dies nur im 32Bit Modus möglich, im 64Bit Modus sind die Befehle länger und das Instruktionsfenster somit zu klein. [vgl. CT06c, INT06, INT07d, INT07e, FOG07] Als Beispiel kann die Befehlsfolge in der folgenden Abbildung betrachtet werden. Der Programmfluss in der Abbildung ist von unten nach oben zu betrachten. Die anschließende Decodierung in echte Mikrooperationen ist in der Abbildung nicht mehr dargestellt, sie betrachtet ausschließlich die Prä- Decodierung. [vgl. CT06c, INT06, INT07d, INT07e, FOG07] Abbildung 4: Beispiel zur MacroOp Fusion (Prä-Decodierung) [vgl. CT06c] Einfache Instruktionen (Register-Move oder Integerberechnungen) übersetzen die Simple-Decoder direkt in Mikrooperationen, komplexere werden von dem Complex-Decoder in mehrere Mikrooperationen umgewandelt. Im Extremfall können dies über zehn Mikrooperationen sein. Aus den Mikrooperationen kann der Complex-Decoder dann gleichzeitig bis zu vier Operationen generieren. Die dekodierten Operationen aus dem Complex-Decode gelangen zusammen mit den drei dekodierten Operationen aus den Simple-Decodern in die Decoded Instruction Queue. [vgl. CT06c, INT06, INT07d, INT07e, FOG07] An dieser Stelle setzt die zweite Stufe der Befehlsverschmelzungen an: in der MicroOp Fusion werden passende Mikrooperationen gebündelt und gemeinsam verwaltet. Dies funktioniert allerdings nur dann, wenn sich genügend ähnliche, d.h. zusammenfassbare, Operationen in der Decoded Instruction Queue befinden. Dieses Vorgehen spart Zeit und Strom, denn je weniger Operationen vom Reorder- Buffer und der Reservation Station verwaltet werden müssen, desto weniger Strom wird verbraucht. [vgl. CT06c, INT06, INT07d, INT07e, FOG07] Bartels, Dinter, Lange Seite 11 von 43

12 Aus Performancegründen haben moderne Prozessoren weit mehr physikalische Register, als es der ursprüngliche x86 Befehlssatz vorsieht. Damit dieser Vorteil zum Tragen kommen kann, müssen die logischen Register des Befehlssatzes auf die physikalischen Register abgebildet werden. Durch diese Vorgehensweise können außerdem viele Pseudo-Abhängigkeiten aufgelöst und so mehr Operationen parallel ausgeführt werden. [vgl. CT06c, INT06, INT07d, INT07e, FOG07] Um dies leisten zu können und um die Registerinhalte später wieder richtig zurückschreiben zu können, werden die Abhängigkeiten der Register (logisch und physikalisch) im Retirement Register File gespeichert; die Zuordnung werden in der Register Allocation Table vorgenommen. So lassen sich allerdings nicht alle Abhängigkeiten auflösen. Um die Pipeline trotzdem optimal auslasten zu können, werden die Befehle entsprechend für die Out-of-Order Ausführung umsortiert. Diese Aufgabe wird vom Reorder-Buffer übernommen. Hier wird auch die ursprüngliche Reihenfolge gespeichert, um diese im Fehlerfall oder bei Interrupts wiederherstellen zu können. Aus dem Reorder- Buffer kommen bis zu vier unabhängige Mikrooperationen pro Takt in die Reservation Station, wo sie auf eine freie Ausführungseinheit warten. [vgl. CT06c, INT06, INT07d, INT07e, FOG07] Für die Abarbeitung sind sechs Ausführungseinheiten verfügbar, die theoretisch auch bis zu sechs Mikrooperationen gleichzeitig verarbeiten können. Theoretisch deshalb, weil bei einem extrem selten auftretenden Fall die 32 Plätze der Reservation-Station, und damit die Pipeline, leerlaufen kann. Das passiert dann, wenn kontinuierlich mehr Befehle verarbeitet werden als von Reorder-Buffer geliefert werden können. Die sechs Ausführungseinheiten bestehen aus drei ALUs, je einer Load/Store Einheit für Adressen und einer Store Einheit für Daten. Außerdem kann in jeder der ALU-Einheiten, aber nicht parallel zu diesen, auch ein MMX oder SSE Befehl verarbeitet werden. Im Unterschied zu anderen Architekturen können hier echte 128Bit MMX/SSE Befehle verarbeitet werden. [vgl. CT06c, INT06, INT07d, INT07e, FOG07] Weitere Takte werden durch eine Verlagerung der AGU (Adress Generation Unit) direkt in die Load/Store Einheiten gespart, dadurch müssen die Adressen nicht erst im Port 0 berechnet werden. Dies ermöglicht es der Integer Ausführungseinheit im Port 0 zur gleichen Zeit eine andere Operation auszuführen. [vgl. CT06c, INT06, INT07d, INT07e, FOG07] Nach dem Berechnen in den Funktionseinheiten werden die Inhalte aus den physikalischen Registern in die logischen Register des Befehlssatzes geschrieben. Hierzu wird wieder auf das Retirement Register File zugegriffen. [vgl. CT06c, INT06, INT07d, INT07e, FOG07] 2.4. Ausblick auf die neue Core-Generation (Penrym) Mit der neuesten Generation der Core-Architektur, Codename Penrym, vollzieht Intel den Shrink auf 45nm. Außerdem werden bei diesem Generationswechsel einige Strukturverbesserungen vorgenommen. So wurde z.b. der shared L2 Cache auf 6MB vergrößert, die Integer- und Floating- Point-Dividierer verbessert (ca. zwei bis drei mal schneller) und einige zusätzliche, Intel spezifische SSE Befehle hinzugefügt (SSE 4.1). [vgl. CT07, RWT07] Bartels, Dinter, Lange Seite 12 von 43

13 3. Hauptspeicher (RAM)- und Chipsatz-Anbindung 3.1. Speicher-Adressierung / -Verwaltung Um die Speicher-Adressierung und -Verwaltung der K8 und Core Prozessor-Architektur zu verstehen, ist eine einführende Erklärung der grundlegenden Befehls-Architektur der beiden Prozessor- Architekturen nötig. Grundlage aller x86 Prozessoren ist die von Intel entwickelte Intel Architektur-32 kurz IA-32, die allgemein auch als x86 Architektur bezeichnet wird. Der 386er von Intel ist der erste Prozessor, der, aus heutiger Sicht, die wichtigsten Funktionen dieser Architektur implementiert. Er ist ein 32 Bit Prozessor, der im Protected Mode eine virtuelle Speicherverwaltung mittels Segmentation und/oder Paging ermöglicht. Die IA-32 Architektur wird bis heute von Intel aber auch von anderen Unternehmen, unter anderen AMD, weiter entwickelt. AMD hat eine neue Grundlagen - Architektur für 64 Bit Prozessoren entwickelt. Diese basiert auf der IA-32 Architektur und erweitert entsprechende Prozessoren um den 64 Bit Long Mode. AMD bezeichnet diese Architektur als AMD64. Sie wurde erstmals mit den auf der K8 Architektur basierenden Opterons 2003 eingeführt. Intel ignorierte die AMD64 Architektur lange Zeit, da Intel eine eigene 64 Bit Architektur namens IA- 64 entwickelt hatte und diese auch bei den Itanium Server Prozessoren einsetzte. IA-64 ist jedoch nur durch Emulation mit der IA-32 Architektur kompatibel. Aus Gründen des Marktdrucks (z.b. Microsoft wollte nur ein 64 Bit Desktop-Betriebssystem entwickeln) und wegen zu hoher Kosten der IA-64 im Desktop-Bereich führte Intel die 64 Bit Erweiterung von AMD in seine IA-32 Prozessoren ein. Intel bezeichnete die Erweiterung erst als IA-32e (so steht es noch in aktuellen Dokumenten), später dann als EM64T und jetzt als Intel 64. IA-32 Prozessoren mit AMD64/Intel 64 Erweiterungen unterstützen folgende Betriebsmodi: Tabelle 1: Betriebsmodi der IA-32 Prozessoren mit AMD64/Intel 64 Erweiterungen Hauptmodi Untermodi OS Virtuelle Adr. Physikalische Adr. Seitengrößen Long 64-Bit Bis zu 64 Bit Bis zu 52 Bit 4 KB, 2 MB Mode Mode K8/K10/Core: 48 Bit K8/K10: 40, Core: 36 Bit (K10: 1 GB) 64 Bit (AMD64/ Compatibility 32 Bit 32 Bit 4 KB, 2 MB, Intel 64) Mode (4 MB) Protected 32 Bit 32 Bit (mit PAE auch mehr 4 KB, 2 MB, Legacy Mode z.b. Core: 36 Bit) (4 MB) 32 Bit Mode Virtual Standard: --- (IA-32) Mode 1 MByte mit 16 Bit Real Mode 16 Bit MByte mit 16 Bit --- Im Legacy-Mode wird aktuell überwiegend der Protected Mode verwendet. Dieser Modus unterstützt Segmentation mit oder ohne Paging. Bei aktiviertem Paging werden standardmäßig 4 KByte, unter anderen Konfigurationen 2 MByte oder 4 MByte große Seiten, unterstützt. Es lassen sich maximal 32 Bit (4 GByte adressierbar) virtuelle in 32 Bit physikalsche Adressen umsetzen und verwalten. Die physikalischen Adressen lassen sich mit Hilfe von physical-address extensions (PAE) erweitern (z.b. beim Core auf 36 Bit (64 GByte adressierbar)), was aber nur auf Mainboards und Betriebssystemen für Server zufriedenstellend funktioniert. Bartels, Dinter, Lange Seite 13 von 43

14 Im Protected Mode bildet der Virtual-8086 Mode den alten Real Address Mode (Real Mode) nach, um alte 16 Bit Programme unter einem 32 Bit Betriebssystem ausführen zu können. Segmentation ist eine flexible aber auch sehr aufwendige Speicherverwaltung. Es wird aus Performance und Ressourcen Gründen empfohlen, sie nicht zu nutzen, was auch die meisten heutigen Systeme umsetzen. Dazu wird der Prozessor so konfiguriert, dass Segmentation größtenteils umgangen wird (Segmentation lässt sich nicht abschalten). Zur Umsetzung dieses sogenannten Flat Memory Modells wird die Segment Adresse (Segment Base Address) auf 0 und die Segment Größe (Limit) auf 4 GByte (Größe des gesamten Speichers) gesetzt. In der Regel wird beim Flat Memory Model Paging dazu verwendet virtuellen Speicher und Speicher-Schutzfunktionen zu nutzen. [vgl. INT97, INT07e, AMD07] Der Long Mode unterstützt im 64-Bit Mode alle neuen Erweiterungen der AMD64/Intel 64 Architektur. Dies sind im Bereich der Speicherverwaltung bis zu 64 Bit virtuelle Adressen (16 ExaBytes adressierbar) und bis zu 52 Bit physikalische Adressen (4 PetaByte adressierbar). Der aktuelle Standard sieht aber erst mal nur 48 Bit virtuelle Adressen (256 Terabyte adressierbar) vor. Der physikalische Adressraum hängt von der Prozessor-Implementierung ab. Um eine schnellere Speicherverwaltung zu ermöglichen, wird im Long Mode das Flat Memory Model in Hardware umgesetzt. Das bedeutet hinsichtlich Segmentation, dass, bis auf wenige Ausnahmen, alle Segment Base Adressen auf 0 gesetzt werden. Die Segment Limits und Attribute (Schutzfunktionen) werden ignoriert. Paging und Physical Address Extensions (PAE) mit erweiterten Schutzfunktionen sind fester Bestandteil der Speicherverwaltung. Unterstützt werden Seitengrößen von 4 KByte und 2 MByte. Es sind aber auch neuerdings Speicherseiten von 1 GByte vorgesehen. Diese werden zurzeit allerdings nur vom K10 unterstützt. Unter dem Long Mode bildet der Compatibility Mode einen Protected Mode nach, um 32 Bit Programme unter einem 64 Bit Betriebssystem ausführen zu können. Im Compatibility Mode ist Segmentation und Paging wie im Protected Mode möglich und es gelten die gleichen Einschränkungen: 32 Bit virtuelle sowie 32 Bit physikalische Adressen und entsprechende Seitengrößen. Der Virtual-8086 Mode wird unter dem Long Mode nicht mehr unterstützt und daher auch keine Real Address Mode Programme. [vgl. INT07e, AMD07, INT07b, INT07d] 3.2. AMD K8 (Athlon 64 X2) Der Speicher-Controller ist bei der AMD K8 Architektur in den Prozessor integriert ( on die ). Dieser arbeitet mit 128 Bit breiten Blöcken und teilt diese in zwei 64 Bit breite Speicherkanäle auf. Um den zwei-kanaligen Betrieb zu gewährleisten, muss er mit Paaren gleicher Speicherriegel bestückt werden. Ursprünglich hatte der K8 ein DDR1 Speicher-Controller. In der neusten Variante wurde er auf DDR2 umgestellt und kann daher maximal mit Paaren von PC (DDR2-800, 400 MHz) Speicherriegeln betrieben werden. Der Speicher-Controller ist mit 128 Bit am Cross Bar-Switch angebunden, der wiederum über den System Request Queue (SRQ) an die jeweiligen Level 2 Caches der Kerne angeschlossen ist. [vgl. CT06b, AMD07b, CT06c] Im 64 Bit Modus (Long Mode) kann der K8 48 Bit virtuelle Adressen (256 Terabyte) in 40 Bit physikalische Adressen (1 Terabyte) umsetzen und verwalten (siehe Abschnitt 3.1). Bartels, Dinter, Lange Seite 14 von 43

15 In der folgenden Abbildung ist ein Ausschnitt aus der K8 Architektur dargestellt: Abbildung 5: Ausschnitt der K8 Architektur [CT07c] Der K8 kommuniziert mit dem Chipsatz über einen seiner drei HyperTransport-Links. HyperTransport ist ein offener Industriestandard, der vom HT-Konsortium vorangetrieben wird, in dem unter anderem AMD Mitglied ist. Jeder Link besteht aus zwei seriellen Punkt-zu-Punkt-Verbindungen, je eine Verbindung pro Richtung. Nach dem Standard 2c können die Punkt-zu-Punkt-Verbindungen alle 2er Potenzen von 2 bis 32 Bit breit sein und mit 200 bis 1400 MHz betrieben werden. In der aktuellen Version der K8 Architektur sind die Punkt-zu-Punkt-Verbindungen 16 Bit breit und werden mit 800 MHz (HT800) oder 1000 MHz (HT1000) betreiben. Theoretisch können somit pro Richtung 3,2 GByte/s (HT800) beziehungsweise 4 GByte/s (HT1000) übertragen werden. [vgl. AMD07b, CT06c] HT-Links können auch dazu verwendet werden, um mehrere CPUs auf einem Mainboard direkt miteinander zu verbinden. Für die Verbindung zweier CPUs werden allerdings kohärenzfähige HT- Links benötigt. [vgl. AMD07b, CT06c] Der K10 unterstützt HT 3.0 und damit z.b. eine theoretische Link-Übertragungsrate von 20,8 GByte/s. Die neue HyperTransport-Version ist aber nur mit neueren Sockeln kompatibel (AM2+). Außerdem wurde beim K10 der Speichercontroller erweitert, so dass er z.b. zwei getrennte 64 Bit oder ein 128 Bit Speichertransfer abwickeln kann. [vgl. AMD07c] 3.3. Intel Core (Core 2 Duo) Der Speichercontroller beim Core ist, wie es früher auch schon üblich war, in den Chipsatz integriert. Als Erklärungsbeispiel soll hier der X38 Express Chipsatz aus Intels aktueller 3er Serie dienen. Der X38 hat wie der aktuelle K8 einen DDR2 Zweikanal-Speichercontroller (jeweils 64 Bit), der entweder mit Paaren von maximal PC (DDR2-800, 400 MHz) Speicherriegeln betrieben werden kann. Der Zweikanal-Speichercontroller des X38 kann aber auch schon mit DDR3 betrieben werden. Dadurch werden Paare von maximal PC (DDR3-1333, 667 MHz) Speicherriegeln unterstützt. [vgl. INT07f, CT06c] Wie auch bei vorherigen Chipsätzen wirbt Intel mit Speicherbeschleunigungs-Technologien, im Fall des 3er Serie Fast Memory Access genannt. Dadurch werden z.b. Speicheroperationen umsortiert, so dass zunächst alle Speicheroperationen auf die aktuell geöffnete Speicher-Seite erfolgen (in einem begrenzten Zeitfenster), um die Zeit für das Öffnen und Schließen von Speicher-Seiten zu minimieren. [vgl. INT07f, INT06b] Bartels, Dinter, Lange Seite 15 von 43

16 In der folgenden Abbildung ist die Anbindung des Prozessors an den Chipsatz dargestellt: Abbildung 6: Anbindung CPU an den Chipsatz und Speicher (X38 Chipsatz) Der X38 Memory Controller Hub (MCH), früher als Northbridge bezeichnet, ist über den Front Side Bus (FSB) mit dem Prozessor verbunden. Der FSB arbeitet mit einem Quadruple Data Rate (QDR) Verfahren, Intel vermarktet es als quadpumped. Es arbeitet also mit vier Datenworten pro Takt. Die Ende 2007 schnellste Variante des FSB (1333FSB) wird mit 333 MHz betrieben und erreicht somit eine theoretische Bandbreite von 10,6 GByte/s. Diese Bandbreite steht im Widerspruch zur Bandbreite von einem Paar PC (DDR2-800, 400 MHz) Speicherriegeln, die theoretisch 12,8 GByte/s übertragen können. Noch gravierender wird der Widerspruch, wenn die schnellst mögliche Variante von DDR3 Speicher eingesetzt wird (PC (DDR3-1333, 667 MHz)). Dieser erreicht bereits im Einkanal-Betrieb die Bandbreite des FSB von 10,6 GByte/s, im Zweikanal-Betrieb sogar 21,2 GByte/s. Aus diesem Grund lohnt sich aktuell die Anschaffung von teureren DDR3 Speicher nicht, denn von diesem Speicher ist keine Leistungssteigerung zu erwarten. [vgl. INT07f] Im 64 Bit Modus (Long Mode) kann der Core 48 Bit virtuelle Adressen (256 Terabyte) in 36 Bit physikalische Adressen (64 GByte) umsetzen und verwalten (siehe Abschnitt 3.1). [vgl. INT07c, CT06c] 3.4. Gegenüberstellung Einer der größten Nachteile des externen Speichercontrollers der Core Architektur ist der durch den FSB entstehende Flaschenhals zwischen Prozessor und Speichercontroller. Der Durchsatz des FSBs ist, wie so oft, der theoretischen Bandbreite des Speichercontrollers im Chipsatz unterlegen (siehe auch Abschnitt 3.3). Noch gravierender wird dieser Engpass durch die Tatsache, dass der FSB auch die Kommunikation zwischen der Peripherie und dem Prozessor bewältigen muss. Bartels, Dinter, Lange Seite 16 von 43

17 Dadurch dass der Übertragungsweg im Verhältnis zum K8 länger ist und das Übertagungsprotokoll beziehungsweise die Frequenz angepasst werden muss, wird die Zugriffszeit (Latenz) in die Höhe getrieben. Das alles reduziert die maximale Speicherperformance. [vgl. CT03, CT06b, CT06c] Beim K8 ist durch die direkte Anbindung an den jeweiligen Kern über den Cross Bar-Switch die Latenz gering. Der Cross Bar sollte auch keinen Flaschenhals darstellen, da dieser, wie eigentlich jeder Cross Bar Switch, laut AMD nicht blockierend arbeitet. Ein Cross Bar-Switch schaltet die Kommunikations-Partner mit voller Bandbreite zusammen und ermöglicht in den meisten Fällen die gleichzeitige Zusammenschaltung mehrerer unabhängiger Komponenten. Die dadurch entstehende Steigerung der Speicherperformance stellt größten Vorteil und daher den Hauptgrund für den Einsatz des internen Speichercontrollers dar. Einen weiteren Vorteil bietet der interne Speichercontroller des K8 bei Systemen mit mehreren Prozessoren auf einem Mainboard. Theoretisch addiert sich die Speicherperformance der einzelnen Speichercontroller hier. In den nachfolgenden Beschreibungen wird beispielhaft von zwei Prozessoren (zwei Sockel) auf einem Mainboard ausgegangen. In diesem Fall sind durch die in jedem Prozessor vorhandenen Speichercontroller zwei Speicheroperationen gleichzeitig möglich. Im Idealfall wird dadurch der Speicherdurchsatz verdoppelt. Voraussetzung ist aber, dass beide Controller mit Speicher ausgestattet sind und ein Betriebssystem das ccnuma (Cache Coherent Non Unified Memory Access) unterstützt. Das Betriebssystem muss unter anderem die Verwaltung des physikalischen Speichers auf die beiden Controller verteilen (ein gemeinsamer Adressraum). Außerdem muss das Betriebssystem dafür sorgen, dass die Daten eines Programms auch im Speicher des Prozessors liegen, auf dessen Kern es gerade ausgeführt wird. Ansonsten müssen die Daten erst über den kohärenten HyperTransport-Link zwischen den Prozessoren ausgetauscht werden. Bei verteilten Daten zwischen den Prozessoren ist zusätzlich auf (Cache-) Kohärenz zu achten. [vgl. AMD06, AMD05 S.96ff, AMD07c S.179ff] Beim Intel Core müssen sich alle Prozessoren auf einem Mainboard den zentralen Speichercontroller im Chipsatz teilen. Bei geteilten Daten zwischen den Prozessoren ist hier das Kohärenz-Protokoll über den langsamen und schon belasteten FSB abzuwickeln. Dieses führt bei Core-Multiprozessorsystemen eher zu einem Einbruch der Speicherperformance. Intel versucht den Performance-Verlust bei ihren Server-Chipsätzen z.b. mit Vierkanal-Speichercontrollern, die die Speicheroperationen flexibel aufteilen können, zu beheben. Mit dem neuen Clarksboro-Chipsatz zeigt Intel ein Vorteil eines zentralen Speichercontrollers auf. Dieser erledigt einen Großteil der Zeit- und Energie-aufwendigen Snooping-Aufgabe der Prozessoren, indem er einen Snoop-Filter-Cache einsetzt. Unter Snooping versteht man, dass Prozessoren am Bus auf Änderungen eigener Cachelines lauschen, um ihre Caches kohärent zu halten. [vgl. CT07c] Bei der K8 Architektur müssen DMA (Direct Memory Access) Zugriffe von anderen Komponenten im PC auf den Speicher über den Chipsatz mittels HyperTransport-Link zum internen Speichercontroller geleitet werden. Dieses stellt insofern einen kleinen Nachteil da, als sich hierdurch der Übertragungsweg verlängert und der Prozessor indirekt an den Zugriffen beteiligt ist. Der externe Speichercontroller der Core Architektur hingegen kann DMA Zugriffe selbständig erledigen, ohne den FSB und Prozessor damit zu belasten. Im Falle vieler DMA Zugriffe zeigt sich ein kleiner Vorteil für eine leichte Überdimensionierung der Speicherbandbreite im Gegensatz zu der FSB-Bandbreite (siehe Abschnitt 3.3). Bartels, Dinter, Lange Seite 17 von 43

18 Einen weiterer Nachteil ist, dass sich der internen Speichercontroller des K8s nur durch Überarbeiten des Prozessors an neue Speicher-Technologien anpassen lässt. Auch wenn für ein Update, z.b. auf DDR3-Speicher, nur der Speichercontroller überarbeitet werden müsste, wäre es auch nötig, die Produktion des Prozessors zu überarbeiten und neu aufzulegen. Daher ist eine Aktualisierung nur bei größeren Architektur-Refreshs wirtschaftlich; das ist aus Sicht des Marketings nachteilhaft. Der aktuelle K8 kann die Bandbreite von DDR2-Speicher nicht einmal vollständig nutzen, da beim Refresh von DDR1 zu 2 nicht alle internen Bandbreiten- und Buffer-Mängel beseitigt worden sind. Diese wurden erst mit dem K10 erledigt. Intel hingegen kann bei unveränderter Prozessorproduktion die Chipsätze und damit den Speichercontroller aktualisieren, wie zum Beispiel die gerade vollzogene Aktualisierung auf die Intel 3er Serie. Daher können die Intel Core Prozessoren bereits jetzt mit DDR3 Speicher betrieben werden, auch wenn eine Aktualisierung nicht immer Sinn ergibt (siehe Abschnitt 3.3). Der größte Nachteil des K8s sind die höheren Entwicklungs- und Produktions-Kosten des internen Speichercontrollers. Die Entwicklungs-Kosten erhöhen sich durch die Entwicklung des Speichercontrollers und den dadurch komplexer werdenden Prozessor. Da der Controller im Prozessor Platz benötigt, wird das Die der zu produzierende Prozessoren größer und damit in der Produktion teurer. Der Sockel wird ebenfalls in der Produktion teurer, da er durch die hinzukommenden Daten-, Adressund Steuer-Leitungen ebenfalls größer und komplexer wird. Das Gegenteil ist beim Core der Fall. Dort fallen keine Zusatzkosten bei der Prozessor-Produktion für den Speichercontroller an. Dafür ist natürlich der Chipsatz aufwendiger und teurer. Bartels, Dinter, Lange Seite 18 von 43

19 4. Cache und TLBs 4.1. Level 2 Cache Es folgt eine Vergleichs-Tabelle und Erklärung, zu den wichtigsten Level 2 Cache Eckdaten, der K8 Architektur in neuester Ausführung mit zwei Kernen und der Core Architektur. Tabelle 2: Eckdaten, L2 Cache AMD K8 (Athlon 64 X2) Intel Core (Core 2 Duo) Größe: 2 x 1048 KB, split cache 1 x 4096 KB, shared cache Organisation: Busbreite: (zum L1) Latenz: (Zugriff) 16-fach assoziativ, 64 Byte cache lines, 16-fach assoziativ, 64 Byte cache lines, write back, exclusive write back, non-inclusive 128 Bit 256 Bit 12 Takte (laut Messung [CT07c] Takte) 14 Takte (laut Messung [CT07c] 14 Takte) Der K8 verfügt in der neuesten Version über ein 1 MByte Level 2 Cache pro Kern. Dieser wird auch als Split Cache bezeichnet. Die beiden Kerne des Cores hingegen teilen sich einen L2 Cache von 4 MByte (Shared Cache). Die Organisation ist in dieser Konstellation fast identisch. Beide sind 16-fach assoziativ mit 64 Byte Cache Lines organisiert und arbeiten mit einer write back Schreibstrategie. Der einzige Unterschied besteht darin, dass der K8 L2 Cache exklusiv arbeitet. Das bedeutet, dass die Daten, die im Level 2 Cache stehen, nicht im Level 1 Cache stehen. Dadurch addieren sich die Level 1 und Level 2 Cache Größen, was zu einer höheren Gesamt-Cache-Größe führt. Ausnahmen gibt es allerdings z.b. können beim Rückschreiben von Daten diese doppelt im Cache vorhanden sein. Beim Core hingegen bezeichnet Intel die Organisation als nicht-inklusiv, was allerdings nicht automatisch exklusiv bedeutet. Hierzu gibt es allerdings keine näheren Ausführungen seitens Intel. Es handelt sich aufgrund des Shared Cache wahrscheinlich um eine Mischform zwischen inklusiv und exklusiv. Zum Auflösen möglicher Cache-Kohärenzen verwendet der AMD K8 das MOESI (modified, owned, exclusive, shared, invalid) Protokoll, der Intel Core das MESI (modified, exclusive, shared, invalid) Protokoll. [vgl. AMD07, INT07e] Die Anbindung an den Level 1 Cache ist beim K8 mit 128 Bit nur halb so breit wie beim Core. [vgl. AMD07b, AMD05 S.268ff, AMD07c S.235ff, INT07c S.39ff, INT07e S.447ff] Gegenüberstellung Level 2 Cache Da beim K8 jeder Kern seinen eigenen L2 Cache hat, kommen sich die Kerne bei L2 Cache-Zugriffen nicht in die Quere. Daraus resultiert eine kürzere Zugriffszeit, allerdings nur solange die Daten beider Prozessor-Kerne von einander unabhängig sind. Andernfalls müssen die Kerne die Daten in ihren jeweiligen L2 Caches über ein aufwendiges Cache-Kohärenz-Protokoll abgleichen. Der Abgleich der Daten kann zumindest über den schnellen Cross-Bar-Switch erfolgen. Die zentrale L2 Cache-Verwaltung des Cores muss die Zugriffe beider Kerne auf den Shared Cache serialisieren, wodurch sich die Zugriffszeit verlängert. Durch die zentrale Verwaltung entfällt die Notwendigkeit für ein aufwendiges Cache-Kohärenz-Protokoll. Der größte Vorteil des Shared Cache Bartels, Dinter, Lange Seite 19 von 43

20 ist die dynamische und flexible Aufteilung des Caches auf die beiden Kerne. Dieses wirkt sich besonders bei Single-Thread-Anwendungen aus, denn hier kann sich ein Kern schlafen legen, während der Andere für die Aufgabe den gesamten L2 Cache nutzen kann. Dieser Vorteil birgt aber auch einen Nachteil. Bei Multi-Thread-Anwendungen können die Prozessor- Kerne ihre Daten gegenseitig aus dem Cache verdrängen. Das schlägt sich in einer höheren Cache- Miss-Rate nieder und drückt die Performance des Gesamtsystems. Der K8 mit zwei Kernen hat im Vergleich zum Core nur 2 MByte L2 Cache. Durch den schnellen, integrierten Speichercontroller muss der K8 mit seinem L2 Cache nicht so dringend die langsamen Speicher-Zugriffe abfangen. Trotzdem würde ein größerer Cache der K8-Preformance bestimmt nicht schaden. Da ein Level 2 Cache heutzutage über 50 Prozent der Chipfläche einnimmt, kann sich AMD, vermutlich aufgrund mangelnder Produktionskapazität, keinen größeren Cache leisten. Das zeigt sich auch beim neuen K10, der zwar einen Level 3 Shared Cache von 2 MByte besitzt, die L2 Caches der vier Kerne wurden aber auf 512 KByte pro Kern verkleinert. Der Core hingegen muss mit seinem doppelt so großen L2 Cache die langen Zugriffzeiten auf den Speicher ausgleichen, um die Kerne auslasten zu können. Wie es aussieht kann Intel sich einen großen, produktionstechnisch teureren Cache gegenüber AMD leisten, denn die neue Core-Generation (Penrym) enthält sogar schon einen 6 MByte Level 2 Shared Cache (24-fach assoziativ) Level 1 Cache Im Folgenden werden die Eigenschaften der Level 1 Cache der beiden Architekturen verglichen. Tabelle 3: Eckdaten, L1 Cache I-Cache: D-Cache: D-Cache-Latenz: (Zugriff) I-Bus-Breite: (zum Kern) D-Bus-Breite: (zum Kern) AMD K8 (Athlon 64 X2) Intel Core (Core 2 Duo) 64 KByte, 2-fach assoziativ, 32 KByte, 8-fach assoziativ, 64 Byte cache lines 64 Byte cache lines 64 KByte, 2-fach assoziativ, 32 KByte, 8-fach assoziativ, 64 Byte cache lines, write back 64 Byte cache lines, write back 3 Takte 3 Takte (laut Messung [CT07c] 3 Takte) (laut Messung [CT07c] 3 Takte) 128 Bit 128 Bit 2 x 64 Bit pro Richtung 128 Bit Dem K8 stehen jeweils für Instruktionen und Daten ein doppelt so großer Level 1 Cache (je 64 KByte) gegenüber dem Core zur Verfügung. Dafür ist der 32 KByte große L1 Daten Cache des Cores, gegenüber dem K8, mit 128 Bit pro Richtung doppelt so breit an den Kern angebunden. Diesen Bandbreitenmangel hat AMD mit dem K10 ausgemerzt und die zwei 64 Bit breiten Ports auf 128 Bit verbreitert. [vgl. AMD07b, AMD05 S.268ff, AMD07c S.235ff, INT07c S.39ff, INT07e S.447ff] Bartels, Dinter, Lange Seite 20 von 43

21 4.3. Translation Lookaside Buffers (TLBs) Translation Lookaside Buffers (TLBs) werden dazu eingesetzt, die Übersetzung von virtuellen zu physikalischen Adressen zu cachen und dadurch zu beschleunigen. Beide hier behandelten Architekturen verwenden eine zweistufige TLB-Hierarchie, um die Vorteile eines kleinen, schnellen Cache und eines großen langsamen Cache zu kombinieren. Der vom TLB adressierbare Speicher hängt sowohl von der Anzahl der TLB-Einträge, als auch von der verwendeten Seitengröße ab. Bei großen Seiten werden weniger TLB-Einträge benötigt, um denselben Speicher adressieren zu können als mit kleinen Seiten. Dadurch können bei großen Speicherseiten die Anzahl der TLB-Einträge reduziert werden, um die Verwaltung und den Zugriff auf den TLB zu beschleunigen. Die TLB-Einträge der unterschiedlich großen Speicherseiten können sowohl in einer einzigen, als auch in verschiedenen Tabellen gespeichert werden. Die von den Architekturen verwendete Technologie konnte nicht zuverlässig bestimmt werden, da die einzelnen Quellen keine eindeutige Aussage trafen. [vgl. AMD07b, AMD05 S.268ff, AMD07c S.235ff, INT07c S.39ff, INT07e S.447ff, INT07b] Es folgen Tabellen und Erklärungen zu den TLB-Eckdaten der jeweiligen Architekturen. Tabelle 4: Eckdaten, TLB, AMD K8 AMD K8 (Athlon 64 X2) Stufe L1 Cache L2 Cache I-TLB Einträge D-TLB Einträge 32 (4 KByte Seiten), 8 (2 MByte Seiten), voll assoziativ 32 (4 KByte Seiten), 8 (2 MByte Seiten), voll assoziativ 512 (4 KByte Seiten), 4-fach assoziativ 512 (4 KByte Seiten), 4-fach assoziativ Beim AMD K8 sind die zwei Stufen jeweils an den Cache-Level Eins und Zwei gebunden. 4 MByte Seiten brauchen in der Level 1 TLB-Stufe zwei Einträge der acht 2 MByte Seiten. AMD hat beim K10 unter anderem in der Level 1 Stufe die 2 MByte Instruktionen-Seiten-Einträge auf 16 verdoppelt und die Daten-TLB-Einträge von 32 auf 48 erhöht. [vgl. AMD07b, AMD05 S.268ff, AMD07c S.235ff] Tabelle 5: Eckdaten, TLB, Intel Core Intel Core (Core 2 Duo) Stufe TLB 0 TLB 1 I-TLB Einträge D-TLB Einträge 16 (4 KByte Seiten), 16 (large pages), 4-fach assoziativ 128 (4 KByte Seiten), 4 (large pages), 4-fach assoziativ 256 (4 KByte Seiten), 32 (large pages), 4-fach assoziativ Der Intel Core besitzt keinen zweistufigen Instruktions-TLB. Auch sind die Stufen des Daten-TLBs nicht wie beim AMD K8 an den Cache-Level gebunden. Es gibt im Gegensatz zum K8 erheblich weniger TLB-Einträge. [vgl. INT07c S.39ff, INT07e S.447ff, INT07b] Bartels, Dinter, Lange Seite 21 von 43

22 5. Prefetching Traditionell implementierte Cache-Steuerungen laden Daten erst dann aus einer nächst tieferen Speicher-Hierarchie-Stufe, wenn diese von einer höheren Stufe angefordert wurden und die Daten nicht bereits im Cache liegen (Cache miss). Um das zeitraubende Nachladen der Daten bei einem Cache-Miss zu minimieren, werden Prefetcher eingesetzt. Es gibt dabei sowohl Software- als auch Hardware-Prefetcher. Die nachfolgenden Beschreibungen beschränken sich auf die Hardware-Prefetcher, diese ergänzen entweder die Cache- Steuerung oder sind als eigenständige Einheiten implementiert. Ihre Arbeitsweise ist ähnlich der Arbeitsweise von Sprungvorhersage-Einheiten. Sie führen Statistiken über die Hit- und Miss-Raten der letzten Zugriffe und deren Adressen, um daraus Zugriffsmuster zu erkennen. Wurden bestimmte Zugriffsmuster erkannt, laden die Prefetcher bereits Daten in den Cache, die vermutlich in nächster Zeit benötigt werden (z.b. Zugriffe auf Arrays). [vlg. CT06c, INT06, RWT07, RWT07b] Beim Prefetching von Daten kann es allerdings vorkommen, dass Daten geladen werden, die nicht benötigt werden. Um die geladenen Daten zu speichern, müssen andere Daten aus dem Cache verdrängt werden. Dadurch kann es vorkommen, dass die Prefetcher kontraproduktiv arbeiten und die Performance senken. Um die Effizienz der Hardware-Prefetcher zu steigern, können die meisten Prefetcher in den hier behandelten Architekturen per Software beeinflusst werden. Außerdem sollten sie nur aktiviert werden, wenn die benötigten Speicher und Lade-Einheiten sowie Busse gering bis nicht belastet werden. Die meisten im nachfolgenden behandelten Prefetcher arbeiten nur mit 4 KByte Seiten performance steigernd. [vlg. CT06c, INT06b, RWT07, RWT07b] 5.1. AMD K8 (Athlon 64 X2) Der AMD K8 verfügt in der Dual-Core-Version über drei Prefetcher-Einheiten. Zum Einen steht ein einfacher L1 Instruktion Prefetcher zu Verfügung. Dieser lädt jeweils die nächste auszuführende Instruktion vor. Dazu ist der L1 Instruktion Prefetcher mit der Sprungvorhersage verbunden. So ist es möglich, dass jeweils die beiden nächsten möglichen Anweisungen bei einer Sprunganweisung geladen werden können. [vgl. AMD05] Von der nächsten Prefetcher-Einheit stehen jedem Kern jeweils eine zur Verfügung. Hierbei handelt es sich um einen einfachen L2 Adjacent Cacheline Prefetcher (Streaming Prefetcher). Dieser erkennt wenn auf nebeneinander liegende Speicherplätze zugegriffen wird und lädt automatisch die nachfolgenden Speicherplätze in den L2 Cache. Das funktioniert beim K8 aber nur, wenn keine Cacheline ausgelassen wird. [vgl. AMD05] AMD hat dem K10 weitere Prefetcher zur Verfügung gestellt, zum Beispiel dem Level 1 Daten Cache. [vgl. AMD07c] Bartels, Dinter, Lange Seite 22 von 43