3. Architekturen moderner Prozessoren 3.1 Einführung (1)

Transkript

1 3.1 Einführung (1) Nahezu jeder Prozessor in einem Desktop-Rechner (der auf oder unter dem Tisch steht) und in einem Server- Rechner (auf dem man sich von der Ferne einloggt und dort rechnet) nutzt heute Caches (s. Kap ) Pipelining Superskalare Befehlsabarbeitung Out-of-order execution (Abarbeitung der Befehle entgegen der vom Compiler erzeugten Reihenfolge) Diese Prinzipien werden wir im Kapitel 3 behandelt , Folie 1

2 3.1 Einführung (2) Ferner: Evolution der Prozessor-Architektur Stationen dieser Evolution von CISC bis Multi-Core Complex Instruction Set Computing (CISC) Reduced Instruction Set Computing (RISC) Superskalare Architekturen Very long instruction Word (VLIW) Explicitly Parallel Instruction Computing (EPIC) Multithreading (Simultanes Multithreading (SMT) Hyperthreading (HT)) Multikern-Architekturen , Folie 2

3 3.2 CISC-Architekturen (1) Am Anfang war CISC (Complex Instruction Set Computer): Technik der Mikroprogrammierung ist CISC So benannt in den 1980er Jahren nachdem RISC aufkam Vorteile CISC: Erforderliche Speicherkapazität geringer es erfolgt Expansion eines CISC-Befehls im Prozessor Abbildung Makrobefehl -> Folge von Mikrobefehlen (Mikroprogramm) (s. Bsp. Folie 7, Kap 2) A B A Könnte z.b so kodiert sein SUB A B Kostet weniger Speicher als , Folie 3

4 3.2 CISC-Architekturen (2) Weiterer Vorteil: in den 60er Jahren vorhandene sog. semantische Lücke überbrückbar Durch Mikroprogramm einen Hochsprachen-Befehl implementieren Gilt für Chip-Hersteller und deren Compiler-Bauer Details zu semantischer Lücke, s. Vorlesung SP Beispiel: Switch-Befehl als Mikroprogramm Befehl in Hochsprache switch ( i ) { case 0 : a = 1 ; break ; case 1 : a = 2 ; break ; } ; Lücke durch Mikroprogramm überbrücken (fiktive Syntax) 0: i -> ACCU 1: JMP if ACCU=0 TO 6 2: DECR ACCU 4: JMP if ACCU=0 TO 8 5: RETURN 6: SET a=1 7: RETURN 8: SET a=2 9: RETURN , Folie 4 nackte Menge der 10-Befehlsmuster der Maschine Entsprechende Mikrobefehle

5 3.2 CISC-Architekturen (3) Lange Zeit der Zufriedenheit mit diesem Ansatz Konzept der Mikroprogrammierung zuerst in Großrechner eingeführt dort auf in der Kapazität limitierte Ferritkernspeicher ausgerichtet CISC Mikroprozessor-Architekturen waren dem Stand der Großrechnertechnik bis Anfang der 80er Jahre angepasst Gründe: wohl einfacher adaptierbar technologische Gründe für diese Orientierung gab es nicht, denn Mikroprozessoren waren von Anfang an mit Halbleiter-Arbeitsspeichern ausgestattet , Folie 5

6 3.2 CISC-Architekturen (4) Mit der Zeit: immer neue Prozessoren Erweiterung der Befehlssätze Zwang zur Abwärtskompatibilität Folge der Entwicklung immer größere und undurchschaubarere Befehlssätze Komplizierte Adressierungsarten (z.b. VAX11/780 verwendete 22 verschiedene Adressierungsarten) Befehle mit sehr unterschiedlichen Längen Compiler-Bauer verwendeten nur noch kleine Teilmenge des Befehlssatzes , Folie 6

7 3.2 CISC-Architekturen (5) Beispiel: Eigenschaften Befehlssätze CISC-Prozessoren , Folie 7

8 3.2 RISC-Architekturen (1) Die Zeit war reif für Neues: RISC-Prozessoren (Reduced Instruction Set Computer) Prozessoren der vierten Generation RISC-Architekturen gekennzeichnet durch Elementare und kleine, einheitliche Maschinenbefehlssätze einheitliche (dadurch aber auch redundante) Befehlsformate, die schnell dekodierbar sind Operanden- und Befehlsholphase während eines Grundtaktes ausführbar Adressrechnungen werden durch explizite Befehle ausgeführt Vorteil: keine komplizierten Adressierungsarten in Befehlen und damit verbundene Adressierungsberechnungen Load-Store-Architektur Alle Operanden liegen in Registern vor Keine Befehle, in denen ein Operand direkt auf Speicheradresse verweist Wenn nicht, dann Operanden laden bzw. speichern durch explizite Lade- /Speicher befehle , Folie 8

9 3.2 RISC-Architekturen (2) große universelle Registersätze festverdrahtete Leitwerke kein Mikroprogramm; kein Mikroprogrammspeicher Schafft Platz auf dem Chip für Caches und Register Jeder RISC-Befehl wird direkt in binäres Befehlsmuster dekodiert konsequentes Ausnutzen von Fließbandverarbeitung (Pipelining) nach Möglichkeit alle Befehle bis auf Laden/Speichern innerhalb eines Taktes abzuwickeln (im Durchsatz) war später jedoch nicht mehr konsequent durchzuhalten (z.b. numerische Gleitkomma-Operationen) ab Pentium Pro wird in Intel-Prozessoren komplexer Maschinenbefehl intern in eine Folge einfacher nach dem RISC-Prinzip abzuarbeitender Befehle zerlegt Erforderlich: Zusammenspiel von optimierenden Compiler und RISC- Prozessor-Architektur, um Fließbandverarbeitung auch effizient auszunutzen , Folie 9

10 3.2.1 RISC-Architekturen Pipelining (1) Fließbandprinzip (Pipelining) Übertragung des z.b. in der Automobilindustrie angewandten Prinzips der überlappten Bearbeitung von Arbeitsteilschritten auf den Befehlszyklus eines Prozessors Phasen des Befehlszyklus streng synchron arbeitenden unabhängigen Teilwerken zuweisen jeder einzelne Befehl durchläuft sequentiell alle Teilwerke Gegenteil: Nicht zeitlich überlapptes Abarbeiten der Befehle (s. Bild) , Folie 10

11 3.2.1 RISC-Architekturen Pipelining (2) Elementare Phasen des Befehlszyklus BH: Befehl holen inkl. Befehlszähler inkrementieren BD: Befehl dekodieren OH: Operanden holen BA: Befehl ausführen ES: Ergebnisse zurückschreiben (in Register bzw. in Speicher bei Store- Operationen) inkl. Befehlszähler im Falle eines Sprungs überschreiben 5 Phasen 5 Teilwerke 1. Befehl BH BD OH BA ES 2. Befehl BH DE OH BA ES 3. Befehl Beispielhaft; kein ehernes Gesetz! kann in der Realität viel fein-granularer sein, z.b. Intel P4-Architekturen über 30 Stufen [in Hennessy/Patterson BD/OH zusammengefasst, extra Phase für Zugriff auf Arbeitsspeicher] Zeit , Folie 11

12 3.2.1 RISC-Architekturen Pipelining (3) überlapptes Arbeiten 1. Befehl BH BD OH BA ES 2. Befehl BH DE OH BA ES 3. Befehl Zeit BH BD OH BA ES 1. Befehl BH BD OP BA ES 2. Befehl BH BD OH BA ES 3. Befehl BH BD OH BA ES 4. Befehl Dauer eines Befehls mindestens genauso lang wie zuvor (Latenzzeit) evtl. länger, denn Fließband muss sich nach der langsamsten Komponente richten Durchschnitt (Durchsatz) steigt an im Idealfall auf das n-fache bei n Teilschritten , Folie 12

13 3.2.1 RISC-Architekturen Pipelining (4) Viele Eierköpfe gleichzeitig unterwegs , Folie 13

14 3.2.1 RISC-Architekturen Pipelining (5) Leistungssteigerung bei vier Befehlen? anstatt 20 Zeiteinheiten nur (bitte selbst überlegen wie viele) Zeiteinheiten Welche Leistungssteigerung ist (theoretisch) möglich? Allgemein gilt: jede Pipeline-Stufe verursacht gewissen Zusatz-Aufwand für Datenbewegung Zwischenspeicherung im Datenfluss zwischen einzelnen Stufen kritisch bei vielen Unterbrechungen im synchronen sequentiellen Ablauf Steuerlogik zur Behandlung von Register- und Speicher- Abhängigkeiten steigt mit Zahl der Stufen höherer Gatteraufwand für Steuerung der Stufen als für die Stufen selbst , Folie 14

15 3.2.1 RISC-Architekturen Pipelining (5) Pipeline dominiert von langsamster Stufe Zykluszeit τ einer Pipeline (bestimmt zugleich Takt = 1 /τ ) τ = max ( τ ) i + d = τ m + d 1 i i τ m = maximale Stufen-Verzögerung k = Anzahl Stufen d = Zeitverzögerung bedingt durch Zwischenspeicherung k Gesamtzeit T k zur Bearbeitung von n Instruktionen k [ ( 1) ] T = k + n τ , Folie 15

16 3.2.1 RISC-Architekturen Pipelining (6) erreichbarer Speed-Up S k Verhältnis von Ausführungszeit T 1 ohne Pipeline zur Ausführungszeit T k in einer Pipeline mit k Stufen nkτ nk Sk = T1 / Tk = = k + ( n 1) τ k + ( n 1) [ ] lim n S k nk = = k + ( n 1) k , Folie 16

17 3.2.1 RISC-Architekturen Pipelining (7) Kurvenverlauf des Speed-Up S k in Abhängigkeit der Anzahl Instruktionen n für verschieden große Anzahl an Stufen k Speed-Up 12 Stufen 9 Stufen 6 Stufen #Instruktionen (10^x) , Folie 17

18 3.2.1 RISC-Architekturen Pipelining (8) Je mehr Stufen um so später läuft Kurve in Sättigung Wunderbar: dann möglichst viele Pipelinestufen k realisieren? Damit ist auch Chiptakt reduzierbar Je mehr Stufen desto kürzere Laufwege von einer Stufe zur nächsten Kürzere Laufwege -> schnellerer Takt (Erklärung s. Skizze Tafel) Preis für potentiellen Gewinn zusätzlicher Pipeline-Stufen zu zahlen (s. nächste Folie) , Folie 18

19 3.2.1 RISC-Architekturen Pipelining (9) Anstieg HW-Kosten Zwischen Pipelinestufen müssen Daten gefangen werden wg. Entkopplung der einzelnen Stufen, d.h. zwischen einzelnen Stufen liegen Register Je mehr Stufen je mehr Register Pipeline-Einschwingphase erhöht sich je mehr Stufen gegeben Damit Anstieg der Latenzzeit pro Befehl Nicht so schlimm könnte durch höheren Durchsatz kompensiert werden Energieverbrauch nimmt zu Kein Beitrag zu GreenIT Wahrscheinlichkeit leerer Pipeline-Zyklen steigt bei Datenabhängigkeiten bei Verzweigungen , Folie 19

20 3.2.1 RISC-Architekturen Pipelining (10) Problem: Datenabhängigkeiten (sog. Datenhazards) Ein Befehl benötigt Ergebnis des unmittelbar vorherigen Befehls Beispiel: Befehle MUL R1, R2 R3 ADD R3, R1 R5 sind nacheinander in Pipeline MUL R1,R2 R BH BD BH OH BD 4 BA OH 5 ES BA 6 7 RS 8 R1 R2 noch nicht in R3 zurückgeschrieben! Erfolgt erst zum Zeitpunkt 5 (RS-Phase MUL-Befehl) ADD R3, R1 R5 Details Modul Rechnerarchitektur (WPF - Rechnerarchitektur) , Folie 20

21 3.2.1 RISC-Architekturen Pipelining (11) Probleme: Verzweigungen Sprünge (sog. Steuerungshazards) Nächster Befehl in Pipeline ist nicht der Richtige t 40: if (R1 == R2) jmp 72 BH BD OH BA ES 44: (R1 and R12) R5 48: (R1 or R12) R5 52: (R14 add R2) R : (R12 add R2) R2 Lösung: statische und dynamische Sprungvorhersagen (sog. Spekulative Befehlsausführung) Details: Modul Rechnerarchitektur Bachelor 5.Sem BH BD BH OH BD BH , Folie 21 BA OH BD ES BA OH ES BA ES Erst nach Zeitschritt 4 steht fest, wie Vergleich (R1==R2) ausgeht. Der nächste Befehl in der Pipeline ist 44, evtl. falscher Befehl.

22 3.2.1 RISC-Architekturen Pipelining (12) Nochmaliges Beispiel Sprungbefehl (detailliertere strukturelle Sicht der Vorgänge in den Stufen) Zeitpunkt 0: 1.Stufe 2.Stufe 3.Stufe 4.Stufe BH BD OH BA 40: if (R1 == R2) jmp 72 44: (R1 and R12) R5 48: (R1 or R12) R5 52: (R14 add R2) R2 Registerinhalte.. 72: (R12 add R2) R2 R1: 0 R8: 9 R2: 0 R9: 10 R3: 2 R10: 23 R4: 1 R11: 34 R5: 23 R12: 15 R6: 4 R7: , Folie 22

23 3.2.1 RISC-Architekturen Pipelining (13) Zeitpunkt 1: 1.Stufe 2.Stufe 3.Stufe 4.Stufe BH BD OH BA 44: (R1 and R12) R5 48: (R1 or R12) R5 40: if (R1 == R2) jmp 72 52: (R14 add R2) R2.. 72: (R12 add R2) R2 Registerinhalte R1: 0 R8: 9 R2: 0 R9: 10 R3: 2 R10: 23 R4: 1 R11: 34 R5: 23 R12: 15 R6: 4 R7: , Folie 23

24 3.2.1 RISC-Architekturen Pipelining (14) Zeitpunkt 2: == -Vergleich ist auszuführen 1.Stufe 2.Stufe 3.Stufe 4.Stufe BH BD OH BA 48: (R1 or R12) R5 52: (R14 add R2) R2.. 72: (R12 add R2) R2 44: (R1 and R12) R5 40: if (R1 == R2) jmp 72 Registerinhalte R1: 0 R8: 9 R2: 0 R9: 10 R3: 2 R10: 23 R4: 1 R11: 34 R5: 23 R12: 15 R6: 4 R7: , Folie 24

25 3.2.1 RISC-Architekturen Pipelining (15) Zeitpunkt 3: Operanden werden aus R1 und R2 geholt 1.Stufe 2.Stufe 3.Stufe 4.Stufe BH BD OH BA 52: (R14 add R2) R2.. 72: (R12 add R2) R2 48: (R1 or R12) R5 44: (R1 and R12) R5 40: if (0 == 0) 72 Registerinhalte R1: 0 R8: 9 R2: 0 R9: 10 R3: 2 R10: 23 R4: 1 R11: 34 R5: 23 R12: 15 R6: 4 R7: , Folie 25

26 3.2.1 RISC-Architekturen Pipelining (16) Zeitpunkt 4: Ergebnis Vergleich wird berechnet 1.Stufe 3.Stufe 2.Stufe 4.Stufe BH BD OH BA.. 72: (R12 add R2) R2 52: (R14 add R2) R2 48: (0 or 15) R5 44: (0 and 15) R5 Ergebnis des Vergleichs 0==0 ist true Nächster Befehl in der Pipeline sollte somit 72 sein Registerinhalte R1: 0 R8: 9 R2: 0 R9: 10 R3: 2 R10: 23 R4: 1 R11: 34 R5: 23 R12: 15 R6: 4 R7: 8 Der nächste Befehl in Stufe 3 ist aber Befehl , Folie 26

27 3.2.2 RISC-Architekturen Superskalare Architekturen (1) Weitere Entwicklung: Superskalare Recheneinheiten Gruppierung von mehreren Befehlen, die nach dem Fließbandprinzip abgearbeitet werden BH BD OH BA ES BH BD OH BA ES BH BD OH BA ES BH BD OH BA ES BH BD OH BA ES BH BD OH BA ES BH BD OH BA ES BH BD OH BA ES BH BD OH BA ES 1. Befehl 2. Befehl 3. Befehl 4. Befehl 5. Befehl 6. Befehl 7. Befehl 8. Befehl 9. Befehl Zeit , Folie 27

28 3.2.2 RISC-Architekturen Superskalare Architekturen (2) erfordert mehrere Rechenwerke heute Stand der Technik , Folie 28

29 3.2.2 RISC-Architekturen Superskalare Architekturen (3) Technik eigentlich alt: übernommen von Supercomputern (CDC6600) gleichzeitige Anwendung von Operationen auf einzelne Komponenten eines Vektors (Vektorrechner) nicht alle Operationen sind Vektoroperationen skalare Werte müssen auch berechnet werden dennoch Prozessor mit mehreren Rechenwerken besser als skalarer, eben superskalar Anwendung auf Befehle benötigt Befehlsgruppierer Umordnung sequentiell einlaufender Befehle zur Laufzeit, um sie parallel auszuführen (dynamische Parallelisierung) allgemeines Prinzip superskalarer Rechner!! keine direkte Parallelität (vom Compiler erzeugt) Herausziehen von Parallelität aus sequentiellem Befehlsstrom in der Hardware , Folie 29

30 3.3 VLIW, Multi-Threading, EPIC (1) Im weiteren zeitlichen Verlauf neue Ansätze entwickelt VLIW, Multi-Threading, EPIC Generell die Frage, wer parallelisiert? die Software: d.h. Compiler (statisch) Vorteil: macht Hardware einfacher Vorteil: Software erfasst ganzes Programm Im Gegensatz zur Hardware, die nur Ausschnitt erfasst oder die Hardware: d.h. das Leitwerk im Prozessor (dynamisch) Vorteil: Hardware kann besser auf Situationen bedingt durch Verzweigungen reagieren Erfasst somit besser den dynamischen Ablauf , Folie 30

31 3.3.1 VLIW (1) VLIW (very long instruction word) Parallelität (paralleles Befehlswort) vom Compiler erzeugen Prozessor hat viele ALUs - jeder ALU genau einen Teil des langen Befehlswortes zuordnen Erfordert Analyse Datenabhängigkeitsgraph (DAG) Beispiel: 1: ADD R2, R3 R1 2: MUL R4, R5 R6 3: SUB R6, R1 R7 4: ADD R8, R9 R10 5: DIV R10, R6 R11 6: ADD R7, R11 R12 7: STORE R12 X DAG : ADD R2, R3 R1 2: MUL R4, R5 R6 4: ADD R8, R9 R10 3: SUB R6, R1 R7 5: DIV R10, R6 R11 6: ADD R7, R11 R12 7: STORE R12 X , Folie 31

32 3.3.2 EPIC (1) VLIW: heute häufig in Digitalen Signalprozessoren (DSP) eingesetzt In anderen Architekturen: kaum Bedeutung mehr EPIC (Explicitly Parallel Instruction Computing) Kombiniert superskalar und VLIW Compiler gruppiert wo möglich und gibt Hinweise (sog. Prädikation) an Hardware für dynamische Befehlsgruppierung Realisiert in INTEL Itanium-Architekturen , Folie 32

33 3.3.2 EPIC (2) Beispiel Weit voran getriebene spekulative Befehlsausführung Beide Verzweigungsstränge werden gleichzeitig ausgeführt EPIC vereint superskalaren und VLIW Ansatz Geht davon aus, dass Instruktionen 4 und 5 bzw. Instruktionen 8 und 9 auch keine Abhängigkeiten aufweisen , Folie 33

34 3.3.3 Multi-Threading (1) Multithreading-Architekturen (vielfädige Architekturen) Rechenwerke werden nicht mit einzelnen Befehlen gefüttert, sondern mit Befehlen aus Threads (Programmfäden) Thread? Abgespeckter Prozess Mehrere Threads gehören zu einem Prozess Threads untereinander weitgehend unabhängig Zuteilung Threads zu Rechenwerken (Scheduling) geschieht in der Hardware Thread 1 Rechenwerk 1 Prozess Thread 2 Rechenwerk 2 Thread 3 Rechenwerk , Folie 34

35 3.3.3 Multi-Threading (2) Simultanes Multi-Threading Variante davon bei INTEL als Hyper-Threading bezeichnet logische Prozessoren auf einem physikalischen Prozessor Antrieb für diese Entwicklung: überproportionaler Anstieg an elektrischer Leistung und Chip-Fläche gegenüber Zuwachs an Rechenleistung , Folie 35

36 3.3.3 Multi-Threading (3) Parallelismus auf Thread-Ebene Zeit-Scheiben Multi-Threading (time-slice multi-threading) Jeder Thread bekommt festes zeitliches Raster zugeteilt Nach Ablauf Umschalten auf anderen Thread Ereignis-gesteuertes Multi-Threading (switch-on-event multithreading) Schalten bei Ereignissen, die lange Latenzen nach sich ziehen Simultanes Multi-Threading ohne Schalten, sondern Auswählen logische Prozessor durch Architekturzustand charakterisiert Eigenen Registersatz Eigenen Befehlszähler Maschinenzustands-Register Eigenes Steuerregister für Unterbrechungen (APIC, advanced programmable interrupt controller) , Folie 36

37 3.3.3 Multi-Threading (5) Beispiel: Hyper-Threading Mischen der Instruktionen von zwei Threads und gleichzeitige Zuweisung auf Ressourcen Zwei aufeinander folgende Befehle aus verschiedenen Threads weisen zumeist keine Datenabhängigkeiten auf Verarbeitungsprinzip (vereinfacht) , Folie 37

38 3.4 Multi-Core-Architekturen (1) Leistungssteigerung bis ca Primär durch Drehen an der Taktschraube Sekundär durch intelligentere Architektur Seit 2003/04 Verlagerung hin zur Architektur , Folie 38

39 3.4 Multi-Core-Architekturen (2) Erhöhung des Taktes stößt an Grenzen wegen Energiebedarf , Folie 39

40 3.4 Multi-Core-Architekturen (3) Antwort: Multicore-Architekturen Mehrere Prozessorkerne auf einem Chip Grund: Technologie: Drehen Taktschraube kostet zu viel Energie (je höher Takt um so schwieriger gleichzeitig V dd zu senken) P 1 = 2 2 diss V dd Architektur: superskalares Prinzip ausgereizt: z.b. dynamische Sprungvorhersage bei mehr als 95% Trefferquote Wayt Gibbs, Spektrum d. Wissenschaft, 03/2005 f f (Frequenz) und V dd (Versorgungsspannung) miteinander korreliert Es war nie die Frage ob, sondern wann und warum: Wann würden die Hersteller von Mikroprozessoren gezwungen sein, einen kleineren Gang einzulegen, warum würde die scheinbar so eiserne Regel alle zwei Jahren ein schnellerer Chip nicht mehr durchzuhalten sein? Mehr Leistung erzielbar nur noch durch echte Parallelität , Folie 40

41 3.4 Multi-Core-Architekturen (4) Technologische Vorteile durch Multi-Core geringere Frequenz einzelner Kerne gleichmäßigere Verteilung der Wärme einzelne Kerne bei (Nicht-)Bedarf abschaltbar Wirtschaftliche Vorteile durch Multi-Core mehr als ein Kern auf einem DIE (Chipkern) spart Produktionskosten zusätzlicher Prozessorkern lässt den Aufwand für die Kühlung nur linear steigen Rechnerarchitektonische Gründe für Multi-Core bisherige Architekturmaßnahmen nahezu ausgereizt Justin R. Rattner, Leiter der Entwicklungsabteilung Systemtechnologie bei Intel»Wir haben das Gesetz des Quadrats gegen uns. Man benötigt exponentiellen Zuwachs der Transistorenzahl, damit steigt aber Chipfläche und Stromverbrauch, um auch nur geringe weitere Verbesserungen bei der parallelen Befehlsverarbeitung zu erreichen « , Folie 41

42 3.4 Multi-Core-Architekturen (5) Vergleich Architekturschema von Multi-Kern-Prozessor vs. Superskalar, Simultanes Multithreading 1 Programmzähler und 1 Registersatz n komplette CPUs n Programmzähler und n Registersätze n logische CPUs mehrere Ausführungs- einheiten Ausführungseinheiten (ALUs) genutzt von allen n logischen CPUs , Folie 42

43 3.4 Multi-Core-Architekturen (6) Beispiel: Intel Core i7 - Architektur verwendet simultanes Multi-Threading (SMT) Skaliert bis zur Anzahl unterstützter Threads 4 SMT Kerne, jeder unterstützt 2 Threads somit 8 logische Kerne , Folie 43

44 3.4 Multi-Core-Architekturen (7) Homogene und heterogene Multikern-Prozessoren Homogene Multikern-Prozessoren Lauter gleiche Kerne Beispiele: Intel Nehalem (Core i7) QuadCore, AMD Istanbul SixCore Heterogene Multikern-Prozessoren Cell PowerPC-Prozessor plus Spezial-Prozessoren für Vektoroperationen , Folie 44

45 3.4 Multi-Core-Architekturen (8) GPGPU (General Purpose Graphics Processing Unit) Graphikkarten-Prozessoren Bsp. GPGPU: GeForce 8080 mehrere Hundert z.t. spezialisierte Kerne , Folie 45

46 Einschub Praktikum Parallele Rechnerarchitekturen Bachelor-Praktikum Parallele Rechnerarchitekturen des Lehrstuhl 3 ab 5.Semester Intensivere Beschäftigung mit Multikern-Architekturen Vergleichende Bewertung verschiedener Multi-Kern-Architekturen Effiziente, architekturnahe Programmierung Umsetzung gängiger Parallelisierungsstrategien anhand ausgewählter Aufgaben (Berechnung Pi bzw. Verzerrbilder) , Folie 46

47 Einschub Praktikum Parallele Rechnerarchitekturen Ablauf Nachrichten-gekoppelte Architekturen Cluster / Multi-Cluster unter OpenMPI 2 Wochen: (4 SWS Einführung + 12 SWS Umsetzung) Homogene Multikern Prozessor-Architektur unter OpenMP 1-2 Wochen: (2 SWS Einführung + 6 SWS Umsetzung) Heterogene Multikern-Prozessorarchitektur am Beispiel Cell und GPGPU (Tesla NVIDIA) 3-4 Wochen: (6 SWS Einführung + 18 SWS Umsetzung) Applikationsspezifische Multikern-Prozessoren in FPGAs 6-7 Wochen: (12 SWS Einführung + 36 SWS Umsetzung) Im Parallelrechner-Labor des Lehrstuhl , Folie 47

48 3.4 Multi-Core-Architekturen (9) Von Multikern- zu Vielkern-Prozessoren GPUs sind vielleicht erst der Anfang Motivation für Vielkern-Prozessoren: Regel von Pollack Rechenleistungszuwachs ~ Anstieg Komplexität Doppelt so großer Einzelkern-Prozessor gemäß Regel von Pollack Verdopplung der Logik, d.h. Komplexität, im Prozessor bringt 40% mehr Leistung , Folie 48

49 3.4 Multi-Core-Architekturen (10) Pollacks Regel rückwärts angewandt Statt einen großen Kern zwei kleinere, halb so große Kerne Leistung nimmt invers quadratisch ab sqrt(1/2) = 70% Somit mit halber Fläche 70% der Leistung des größeren Systems pro Kern Aber nur noch halber Leistungsverbrauch pro Kern In der Summe mehr Leistung als vorher 2 x 70% = 140% Bei gleichem Leistungsverbrauch für 2 Kerne wie beim großen System Schlussfolgerung: einfachere, aber dafür immer mehr Kerne Die Zukunft wird es weisen, ob dies eintritt , Folie 49