2 Homogene und Heterogene Multi-/Vielkernprozessoren

Transkript

1 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.1 Motivation Multikern-Architekturen 2.2 Analyse von Multikern-Prozessoren Energieaspekte Bandbreitenmessung Roofline-Modell 2.3 Beispiele Multi-Core-Architekturen Intel Nehalem AMD Bulldozer 2.4 Heterogene Multi-Core-Architekturen GPGPUs Ausblick: Vielkern-Architekturen SCC: Intels Single Cloud Chip WS 2012/ Folie 1

2 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.1 Motivation Multikern-Architekturen Kein Vortrag in der Technischen Informatik ohne Moore s Law Mooresche Gesetz gilt nach wie vor Zwar Verlangsamung, aber es gilt In der Vergangenheit Höhere Transistorleistung höhere Frequenz Höhere Transistordichte komplexere Architekturen Geringere Energieverbrauch pro Logikoperation gesamte Leistungsdissipation kann unterhalb bestimmter Grenze bleiben Technologie wird weiter voranschreiten Milliarden von Transistoren Jedoch damit verbunden grundlegende Barrieren Z.B. Energieverbrauch WS 2012/ Folie 2

3 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Problem Energie Leistungssteigerung bis ca Primär durch Drehen an der Taktschraube Sekundär durch intelligentere Architektur Seit 2003/04 Verlagerung hin zur Architektur WS 2012/ Folie 3

4 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Problem Energie Erhöhung des Taktes stößt an Grenzen WS 2012/ Folie 4

5 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Problem Energie Antwort: Multicore-Architekturen Mehrere Prozessorkerne auf einem Chip Grund: Technologie: Drehen Taktschraube kostet zu viel Energie P diss V dd Architektur: superskalares Prinzip ausgereizt: z.b. dynamische Sprungvorhersage bei mehr als 95% Trefferquote Wayt Gibbs, Spektrum d. Wissenschaft, 03/2005 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 Jahre ein schnellerer Chip nicht mehr durchzuhalten sein? Mehr Leistung erzielbar nur noch durch echte Parallelität f WS 2012/ Folie 5 f (Frequenz) und V dd (Versorgungsspannung) miteinander korreliert

6 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Problem Energie mehr Kerne geringere Frequenz einzelner Kerne gleichmäßigere Verteilung der Wärme einzelne Kerne bei (Nicht-)Bedarf abschaltbar Wirtschaftliche Gründe mehr als ein Kern auf einem DIE spart Produktionskosten zusätzlicher Prozessorkern lässt den Aufwand für die Kühlung nur linear steigen zusätzlich: 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 «WS 2012/ Folie 6

7 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Problem Energie Somit: die Multikern-Revolution ist da Paralleles Rechnen: keine akademische Nische mehr Homogene und heterogene Multikern-Prozessoren Homogen: Intel, AMD, SUN Heterogen: Cell Am Horizont: Vielkern-Prozessoren 100 und mehr Kerne Intel Polaris Intel SCC (Single Cloud Computer) WS 2012/ Folie 7

8 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Reicht Multikern? Trend der letzten Jahre 2001: 130 nm Technologie Heute: 32 nm Strukturbreite Prognose im Jahr 2007 für Milliarden Transistoren auf 300 mm² Chip-die Ca. 1.5 Milliarden für Logik, der Rest für Cache WS 2012/ Folie 8

9 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Reicht Multikern? Was tun mit vielen Transistoren Trend: heute Wenige große Prozessorkerne 20 bis 100 Millionen Logiktransistoren und großer gemeinsamer Cache Vernünftige Strategie immer größere Kerne zu nutzen? Pollacks Regel Rechenleistungszuwachs ~ Anstieg Komplexität Verdopplung der Logik in Prozessor 40% mehr Leistung WS 2012/ Folie 9

10 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Reicht Multikern? Pollacks Regel veranschaulicht Ganzzahl-Rechenleistung vs. Fläche für neue Mikroarchitekturen Neue Generation Mikroarchitektur für gleiche Prozesstechnologie Quelle: S. Borkar, Intel, Thousand Core Chips A Technology Perspective WS 2012/ Folie 10

11 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Reicht Multikern? Multikern-Architektur Verdopplung von Einzelkern zu doppelt so großen monolithischen Einzelkern-Prozessor 40% Leistungszuwachs Von Einzelkern zu Doppelkern-Prozessor im Idealfall 100% Leistungszuwachs? (Abschätzung s. später inverse Pollack-Regel) Weitere Vorteile (bzgl. Energie) Einzelnen Kern ab-/anschalten Einzelnen Kern mit optimaler Versorgungsspannung und Frequenz betreiben Rechenlast gleichmäßiger verteilen -> keine Hotspots über Die Zuverlässigkeit und Leckströme geringer bei niedrigerer Temperatur WS 2012/ Folie 11

12 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Reicht Multikern? Multikern-Architektur Frequenz und Leistungsverbrauch Transistor-Leistung wird nicht weiter steigen wie bisher Zu große Subschwellwert-Leckströme Versorgungsspannung muss weiter runter gehen Frequenz kann nur moderat ansteigen Schätzung Entwicklung eines 300 mm² Die WS 2012/ Folie 12

13 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Reicht Multikern? 1000 Watt an benötigter elektrischer Leistung nicht machbar Umgekehrte Anwendung von Pollacks Regel Im oberen Energieverbrauchs-Spektrum bleiben und Anzahl Kerne erhöhen Beispiel: Geg.: 1 Milliarde Transistoren Statt 10 Kerne á 100 Millionen Transistoren Lieber 100 Kerne á 10 Millionen Transistoren Oder 1000 Kerne á 1 Million Transistoren WS 2012/ Folie 13

14 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Reicht Multikern? Pollacks Regel rückwärts Leistung nimmt invers quadratisch ab, auf halber Fläche 70% der Leistung des größeren Systems Leistungsverbrauch pro Kern hingegen nimmt linear ab Durchsatz steigt (annähernd) linear mit größerer Anzahl Kerne Flexibilität steigt Kerne nicht notwendig homogen, sondern heterogen Grafikkerne kombiniert mit Einzelkerne (manche Intel COREi3) General-Purpose mit Special-Purpose (SP) Mit lokalem Cache Verbunden mit on-die Verbindungsnetzwerk WS 2012/ Folie 14

15 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Reicht Multikern? Amdahlsche Gesetz Speed-up, d.h. der Geschwindigkeitszuwachs ist nach oben limitiert Für N Kerne gilt: WS 2012/ Folie 15

16 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Reicht Multikern? Grenze gilt für eine auf allen Kernen laufende Applikation Häufig jedoch: viele Applikationen Total Throughput (TPT) WS 2012/ Folie 16

17 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Reicht Multikern? Leistung und Energie Vielkern-System in vorgegebenes Power-Budget integrieren Spannungsreduzierung beste Maßnahme Leistungsbudget zu reduzieren Beliebig technisch schwer realisierbar Autor schlägt diskrete Stufenvorgehensweise vor WS 2012/ Folie 17

18 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Reicht Multikern? On-die Netzwerk zur Verbindung der Knoten notwendig Leistungsverbrauch steigt mit Anzahl Kerne Anforderungen sorgfältig abwägen WS 2012/ Folie 18

19 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Reicht Multikern? Speicherbandbreite Viele Kerne sind auch speicherhungrig Mögliche Lösung? 3D-Stapeltechnik WS 2012/ Folie 19

20 2 Homogene und Heterogene Multi-/Vielkernprozessoren Motivation Multikern-Architekturen Reicht Multikern? Resiliency Elastizität Redundanz zur Tolerierung von Fehlern Ersatzkerne Wenn Schaltkreis (z.b. Kern) altert dann bisher ungenutzten Kern zuschalten Kein TMR (Triple Modular Redundancy) Verdreifachung eines Schaltkreises und Mehrheitsentscheidung über Voter (2 aus 3) Bei Nanoelektronik TMR evtl. nicht mehr tragfähig, da aufgrund höherer Fehlerwahrscheinlichkeit Voter ebenfalls fehleranfällig WS 2012/ Folie 20

21 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Roofline: ein einfaches Leistungsmodell Jeder Desktop- oder Server-Rechner hat heute Caches Pipelining superskalare Befehlsverarbeitung Sprungvorhersage Befehlsausführung außer der Reihe Übergang von Einzelkern- zu Mehrkern-Prozessoren Prozessor(kerne) werden eher unterschiedlicher Homogene vs. Heterogene Prozessoren Verschiedene Funktionalitäten Verschiedene Frequenzen» Siehe Cell, GPGPUs, Intel SCC WS 2012/ Folie 21

22 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Gerade Vielfalt macht einfaches Leistungsmodell wünschenswert Es muss nicht perfekt sein Aber einsichtig Analogie zu den 3Cs bei Cache-Architekturen Compulsory, Conflict, Capacity Seit 20 Jahren einfaches, anerkanntes Modell Hat Schwächen, dennoch nützlich für Rechnerarchitekten und Programmierer Modellgröße anhand der die Leistung gemessen wird Fließkomma-Rechenleistung WS 2012/ Folie 22

23 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Andere Modelle Stochastische, analytische und statistische Leistungsmodelle Sind sehr genau Jedoch häufig schwierig zu behandeln Für nicht-experten nicht unbedingt geeignet Liefern jedoch kaum Einsichten wie Leistung eines Rechners, Compilers oder Programms zu verbessern ist Einfachere alternative Modelle Bound and Bottleneck -Modelle (Schranken und Flaschenhals) Quantifiziert die Systemflaschenhälse Bestes Beispiel: Amdahlsche Gesetz Roofline-Modell gehört ebenfalls zu dieser Klasse WS 2012/ Folie 23

24 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Einfaches zweidimensionales Modell vorteilhaft Hauptursache für Flaschenhals: die off-chip Speicherbandbreite Wunsch: Modell Das Beziehung zwischen Prozessorleistung und off-chip Speicherverkehr ausdrückt Wichtige Größe: Operationelle Intensität Anzahl der Operationen pro geholtem Byte [Flops / Byte] Messgröße für Verkehr zwischen DRAM-Speicher und Caches Nicht zwischen Caches und Prozessor Arithmetische Intensität Pro Takt ein Zugriff auf Operanden des Kernels Quasi: Kosten-freier Zugriff auf Operanden Roofline-Modell 2D-Modell, das operationelle Intensität, Speicherbandbreite und maximal erzielbare Rechenleistung vereint WS 2012/ Folie 24

25 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Operationelle Intensität Arithmetische / Operationelle Intensität für bestimme so genannte Kerneloperationen Kernel: SparseMatrix, Structured Grids (Stencils), Structured Grids (Lattice Methoden), Spektrale Methoden (Fast Fourier Transformationen FFT), Dichte Matrizen, N-Körper-Probleme Skalierung abhängig O(N), O(log(N)), bzw. unabhängig von Problemgröße O(1) WS 2012/ Folie 25

26 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Roofline-Modell Arithmetische bzw. Operationelle Intensität Gemessen in [Flops / Byte] Daraus ableitbar die notwendige Bandbreite fürs Speichersystem Quotient aus erreichbarer Spitzen-Fließkommaleistung / Operationelle bzw. Arithmetische Intensität Floating PointOperations/Sec Floating PointOperations/Byte Erreichbare Rechenleistung Bytes Sec Attainable GLOP/sec Min(Peak Floating Point Performance, Peak Memory Bandwidth Operational Intensity) WS 2012/ Folie 26

27 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Roofline-Modell Graphische Darstellung des Roofline-Modells Opteron X2, Dual 2 GHz Kernel 1: Speicherbandbreiten-begrenzt 0.5 FLOPSs / Byte; Speicherbandbreite begrenzt Leistung auf 8 GFLOPs / sec Kernel 2: Rechenkapazitäts-begrenzt 4 FLOPs / Byte; Speicherbandbreite (max. 16 GB/s) nicht das Problem WS 2012/ Folie 27

28 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Roofline-Modell Graphische Darstellung des Roofline-Modells Peak-Memory-Performance durch Benchmark ermitteln STREAM bekannter Benchmark Autoren schrieben eigenen optimierten Benchmark Beinhaltet spezielle Techniken um optimale Performanz zu erzielen Berücksichtigt Dinge wie vorausschauendes Laden (Prefetching), korrekte Datenanordnung im Speicher auf Adressgrenzen (Data Alignment) Spitzen-Rechenleistung bestimmt durch Abschätzung Maximale Rechenleistung pro Kern Anzahl Kerne WS 2012/ Folie 28

29 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Roofline-Modell Roofline-Modell für zwei Generationen von AMD Opterons (X2 und X4) Gleicher Prozessorsockel, gleiche Anzahl DRAM-Kanäle gleiche Speicherbandbreite X4 doppelt so viele Kerne, doppelte SSE2-Spitzen-Performanz (2 SSE2-Instruktionen / Takt), 2.3 GHz vs. 2.2 GHz (Taktrate X2) etwas mehr als 4-fache Leistung WS 2012/ Folie 29

30 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Roofline-Modell Optimierungsmaßnahmen, um sich möglichst nahe an die Decke der Roofline heranzuschieben ( Adding ceilings to the roofline ) ILP (Instruction Level Parallelism) und SIMD (Single Instruction Multiple Data) anwenden Schleifen aufrollen um Instruktionslatenz zu vermindern Vektorinstruktionen Gute Balance bei Fließkomma-Operationen Gleiche Anzahl an FPADD- und FPMUL-Operationen Schleifen umstrukturieren für Speicherzugriffe pro Schritt Daten in gegebenen Einheitsgrößen ansprechen (unit-stride memory accesses) Speicher-Affinität (in Multiprozessor-Multicores) Multicore-/Speicherchip-Paar Alle Zugriffe auf DRAM innerhalb eines Paars Software-Prefetching Daten durch entsprechenden Befehle lange vor eigentlichem Gebrauch ansprechen und dadurch in Cache laden WS 2012/ Folie 30

31 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Roofline-Modell Dach verschieben für die maximal erzielbare Rechenleistung (Computational Ceiling) WS 2012/ Folie 31

32 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Roofline-Modell Anstiegsgerade nach links verschieben für die maximal erzielbare Speicherbandbreite (Bandwidth Ceiling) WS 2012/ Folie 32

33 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Roofline-Modell Kombination aus beiden Maßnahmen Für welchen Kernel hilft welche Maßnahmenkombination WS 2012/ Folie 33

34 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Roofline-Modell Demonstration und Anwendbarkeit: Angewandt für vier verschiedene Multicore-Architekturen für vier verschiedene Fließkomma-Kernels Xeon e3545 (Clovertown) - SUN UltraSPARC T (Niagara) AMD Opteron 2346 (Barcelona) Cell BE QS20 WS 2012/ Folie 34

35 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Roofline-Modell Eigenschaften der verschiedenen Multikern-Prozessoren FIGURE 7.18 Characteristics of the four recent multicores. Although the Xeon e5345 and Opteron X4 have the same speed DRAMs, the Stream benchmark shows a higher practical memory bandwidth due to the inefficiencies of the front side bus on the Xeon e5345. Copyright 2009 Elsevier, Inc. All rights reserved. WS 2012/ Folie 35

36 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Roofline-Modell Vier Kernels WS 2012/ Folie 36

37 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Roofline-Modell Ergebnisse AMD Barcelona Für Stencil, LBMHD, FFT WS 2012/ Folie 37

38 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Roofline-Modell Ergebnisse AMD Barcelona Für SpMV (Sparse Matrix-Vector) WS 2012/ Folie 38

39 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Roofline-Modell Leistungsanalyse Matrix-Vektor-Multiplikation Spärliche Matrizen (SpMV) FIGURE 7.20 Performance of SpMV on the four multicores. Copyright 2009 Elsevier, Inc. Allrights reserved. WS 2012/ Folie 39

40 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Roofline-Modell Leistungsanalyse Lattice-Boltzmann (LBHMD) WS 2012/ Folie 40

41 2 Homogene und Heterogene Multi-/Vielkernprozessoren 2.2 Analyse von Multikern-Architekturen Roofline-Modell Durch Optimierung erreichte Verbesserungen FIGURE 7.22 Base versus fully optimized performance of the four cores on the two kernels. Note the high fraction of fully optimized performance delivered by the Sun UltraSPARC T2 (Niagara 2). There is no base performance column for the IBM Cell because there is no way to port the code to the SPEs without caches. While you could run the code on the Power core, it has an order of magnitude lower performance than the SPES, so we ignore it in this fi gure. Copyright 2009 Elsevier, Inc. All rights reserved. WS 2012/ Folie 41

42 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Intels Tick-Tock-Prinzip Gleiche Mikroarchitektur Prozess-Technologiesprung Neue Mikroarchitektur mit gleicher Prozess-Technologie WS 2012/ Folie 42

43 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Modularer Aufbau: Architektur besteht aus wenigen Grundbausteinen Mikroprozessor Kern mit eigenem L1 und L2 Cache gemeinsamer L3-Cache Integrated Memory Controller (IMC) Quick Path Interconnect (QPI) Bus controller GPU Kern Dadurch hohe Flexibilität bei der Gestaltung von CPU- Modellen für verschiedene Anwendungsbereiche. WS 2012/ Folie 43

44 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Beispiel: Nehalem Quad-Core Prozessor WS 2012/ Folie 44

45 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Veränderungen beim Loop Buffer (s. Kap , Folie 39) Instruktionen müssen nicht mehr dekodiert werden Mikrooperationen im Puffer ablegen WS 2012/ Folie 45

46 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Energiemanagement Überwachung von Temperatur, Spannung und Stromstärke der einzelnen Cores vorher nur Spannung und Frequenz für alle Kerne global regelbar nun individuelle Anpassung von Taktrate und Spannung nach Bedarf einzelne Cores können in Energiesparmodus versetzt werden ziemlich komplex: ca. 1 Million Transistoren WS 2012/ Folie 46

47 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Turbo Boost Technologie kurzzeitige Übertaktung einzelner Cores möglich automatische Steuerung und Kontrolle durch PCU (Power Control Unit) Thermal Design Power (TDP) muss eingehalten werden Anhebung des Takts in 133 MHz Schritte Beispielszenario: Die Arbeitslast ist ungleich verteilt, so dass nur 2 Cores arbeiten Die beiden anderen Cores sind untätig und gehen in den Energiesparmodus Die PCU erhöht den Takt der aktiven Cores um 2x 133 MHz WS 2012/ Folie 47

48 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Hyperthreading Intels Bezeichnung für Simultaneous Multithreading logische Prozessoren mit eigenem Registersatz, Befehlszähler, logische Prozessoren teilen sich Ressourcen wie Rechenwerke Quasi-parallele Bearbeitung von mehreren Threads möglich Verschiedene Threads weisen meistens keine Datenabhängigkeit auf bessere Auslastung Rechenwerke und damit höherer Gesamtdurchsatz zielt auf RAW-Hazard-Vermeidung WS 2012/ Folie 48

49 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Hyperthreading Veranschaulichung Die blauen Felder symbolisieren Instruktionen aus Thread 1 Die orangenen Instruktionen aus Thread 2 Die gelben Felder stehen für den Leerlauf der Ressourcen WS 2012/ Folie 49

50 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Leistungsvergleich mit aktiviertem und deaktiviertem Hyperthreading WS 2012/ Folie 50

51 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Speicher-Controller Bisher: Speicher-Controller in der Northbridge Nun: Integrierter Speichercontroller bei der Nehalem Architektur geringere Latenzen unabhängig von Mainboard Hardware bessere Transferraten als bei Core 2 Vergleich der Speicher-Performanz von Nehalem und Core 2 WS 2012/ Folie 51

52 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Quick-Path Interconnect Bus QPI schnelle direkte Kommunikation zwischen Prozessoren Kommunikation mit Eingabe/Ausgabe Der ehemalige Front Side Bus konnte diese Anforderungen nicht mehr erfüllen Aufbau eines Mehrprozessorsystems WS 2012/ Folie 52

53 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Cache-Organisation Cache-Hierarchie eigener L1 Cache (32 KB Instruction/ 32KB Data) in jedem Kern eigener L2 Cache (256 KB) in jedem Kern großer gemeinsamer L3 Cache (z.b. 8 MB bei Quadcore) Vergleich der Cache-Latenzen mit der Core-2 Architektur WS 2012/ Folie 53

54 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Cache-Organisation Cache-Kohärenz Mechanismen benötigt für die Cache-Kohärenz bei den einzelnen Cores innerhalb eines Prozessors bei den einzelnen Prozessoren in einem Mehrprozessorsystem WS 2012/ Folie 54

55 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Organisation L3 Cache - Inclusive Cache alle Daten, die sich im individuellen L1 und L2 Cache eines Cores befinden, sind immer auch im L3 Cache vorhanden Somit: wenn sich eine Zeile nicht im L3 Cache befindet, kann sie auch nicht im Cache eines anderen Cores liegen zusätzliche Valid Bits signalisieren in welchen Cores eine bestimmte Cachezeile vorhanden sein könnte positiv: Cachezeile wurde von Core X angefragt. Es kann aber durchaus sein, dass die Zeile mittlerweile nicht mehr im Cache von Core X vorhanden ist negativ: Cachezeile wurde nicht von Core X angefragt und befindet sich daher definitiv nicht im Cache von Core X WS 2012/ Folie 55

56 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Herstellung von Cache-Kohärenz MESIF-Protokoll Modified: Die Zeile wurde verändert und stimmt nicht mehr mit dem Hauptspeicher überein (dirty) Exclusive: Die Zeile ist nur in diesem Cache vorhanden und stimmt mit dem Hauptspeicher überein (clean) Shared: Die Zeile ist clean, wie beim Exclusive-Zustand, aber ein anderer Prozessor hält womöglich eine Kopie der Zeile Invalid: Die Zeile ist ungültig und darf daher nicht mehr gelesen werden Forward: Erweiterung von Shared. Besitzen mehrere Prozessoren die Kopie einer Cachezeile, wird die Zeile bei einem Prozessor mit Forward gekennzeichnet, bei allen anderen mit Shared. Der Prozessor mit dem Forward-Flag beantwortet als einziger alle weiteren Anfragen nach dieser Zeile WS 2012/ Folie 56

57 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur MESIF- (links) vs. MESI-Protokoll (rechts) Annahme: Prozessor links unten und rechts oben haben Kopie MESIF : Nur Prozessor, dessen Cachezeile im Zustand Forward ist, antwortet MESI : alle Kopien im Zustand Shared und alle antworten auf eine Anfrage, z.b von Prozessor rechts unten Folge: höhere Busbelastung WS 2012/ Folie 57

58 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Nehalem-Modelle im Vergleich WS 2012/ Folie 58

59 2.3 Beispiele für Multikern-Architekturen Intel Sandy-Bridge-Architektur Nehalem/Westmere im Vergleich zu Sandy Bridge Quelle Bilder/Informationen: Neu gegenüber Nehalem: Einigermaßen neu : LLC (Last Level Cache) und System Agent Komplett neu : Ringbus Teile der Front-End-Pipeline neu gestaltet WS 2012/ Folie 59

60 2.3 Beispiele für Multikern-Architekturen Intel Sandy-Bridge-Architektur Sandy-Bridge-Mikroarchitektur im Überblick WS 2012/ Folie 60

61 2.3 Beispiele für Multikern-Architekturen Intel Sandy-Bridge-Architektur Einordnung Intel Mikroarchitekturen / Prozessormodelle Modellfamilie Codebezeich nung Core 2 Quad Core i7 9xx Yorfkfield Bloomfield / Westmere Core i7 8xx & i5 7xx Core i5 6xx & i3 5xx Core i7, i5, i3 Lynnfield Clarkdale Sandy Bridge Phenom II Deneb / Thuban Erscheinungs datum Ende 2007 Nov / März 2010 Sep Jan Jan Feb Sockel AM3 max. Takt [GHz] 3,2 3,33 / 3,33 3,06 3,6 3,4 3,6 / 3,3 Fertigung 45 nm 45 nm / 32 nm Die-Größe [mm²] 45 nm 45 nm + 32 nm 32 nm 45 nm 2x / bis 216 max. 258 / 346 Transistoren [Mio] max. TDP [Watt] / bis 995 max. 758 / WS 2012/ Folie 61

62 2.3 Beispiele für Multikern-Architekturen Intel Sandy-Bridge-Architektur Sandy-Bridge Frontend- Pipeline Besteht aus Sprungvorhersageeinheit Befehlsholeinheit Dekodieren WS 2012/ Folie 62

63 2.3 Beispiele für Multikern-Architekturen Intel Sandy-Bridge-Architektur Befehlsholeinheit Nutzt Mikrobefehls-Cache (µop- Cache) enthält bereits in RISC-µOP-Befehle dekodierte CISC-Befehle Funktionsweise analog zu Loop Buffer (s. S. 45) Spart Energie und Zeit im Falle einer notwendigen Dekodierung Unterschied zu Loop Streaming Detector (LSD) bei Nehalem nicht auf eine bestimmte Schleife beschränkt Sprungvorhersage 2-Bit-Vorhersage wurde weiter optimiert (s. Kap. 1, S. 41) (strongly taken, weakly taken, weakly not taken, strongly not taken) Mehrere Vorhersagebits für verschiedene Sprungbefehle verwenden» Spart Platz -> Vorhersagen für mehre Sprünge möglich Bei dicht aufeinanderfolgenden Sprungzielen Präfix der Sprungziele nur einmal speichern (s. Branch History Tabelle in Kap. 1) spart Speicherplatz und damit Energie WS 2012/ Folie 63

64 2.3 Beispiele für Multikern-Architekturen Intel Sandy-Bridge-Architektur Sandy-Bridge Backend-Pipeline Besteht aus Register-Allokierung / Registerumbenennung Out-of-order Ablaufplanung, Out-of-order Ausführung Retirement oder Reorder (Rückschreiben in Scoreboard/Tomasolu) WS 2012/ Folie 64

65 2.3 Beispiele für Multikern-Architekturen Intel Sandy-Bridge-Architektur Register-Allokierung / Registerumbenennung PRF (Physical Register File) Kein Kopieren in Reservierungstationen / Mitführen von Kopien der Operanden in Pipelinestufen (s. Pipelineregister, Puffer Reservierungsstationen, Kap. 1, S. 31, 79) Stattdessen, einen große Registersatz und Zeiger in Pipelinestufen mitführen» Zeiger geringere Anzahl Bits -> spart Energie WS 2012/ Folie 65

66 2.3 Beispiele für Multikern-Architekturen Intel Sandy-Bridge-Architektur Memory-Cluster zur Erhöhung der Bandbreite zwischen Cache/Load-Store-Einheiten Nehalem drei Lade-/Speichereinheiten zum Laden von Daten/ Adressspeicherung / und Speichern der Daten Sandy Bridge die ersten beiden Einheiten nun symmetrisch Ferner höhere Bandbreite (48 Bytes/Zyklus statt 32 Bytes/Zyklus) WS 2012/ Folie 66

67 2.3 Beispiele für Multikern-Architekturen AMD-Magny-Cours Opteron-Architektur Magny-Cours Hybrid aus zwei 6-Kern-Prozessoren Gedacht für Aufbau von Servern aus 2P/4P (2/4-Prozessoren) aufgebauten Multiprozessorsystemen ergibt maximal 48 Kerne Kombiniert laut AMD Fortschritte in der Si-Technologie Aufbautechnik Verbindungen Cache-Kohärenz-Protokoll (interessant hier für Vorlesung) hält Energieverbrauch (power envelope) früherer Opterons ein WS 2012/ Folie 67

68 2.3 Beispiele für Multikern-Architekturen AMD-Magny-Cours Opteron-Architektur Prozessorknoten integriert folgende Module Sechs x86-64 Kerne Gemeinsamer 6-MByte L3 Cache Vier HyperTransport3 Anschlüsse (Ports) 2 DDR3 Memory Kanäle WS 2012/ Folie 68

69 2.3 Beispiele für Multikern-Architekturen AMD-Magny-Cours Opteron-Architektur Prozessor Out-of-order 3-fach superskalar holt und dekodiert bis zu drei x86-64 Instruktionen pro Zyklus x86-64 Instruktionen (CISC) variabler Länge werden in Mikrooperationen (Mikroprogramm aus RISC-Befehlen) fester Länge gewandelt Werden auf zwei unabhängige Ablaufplaner (Scheduler) verteilt für Integer- und für Fließkomma-Operationen bzw. sog. Multimedia-Operationen (SIMD, Vektor-Operationen) Scheduler können jeweils bis zu 9 Mikrooperationen folgenden Ressourcen zuteilen drei Integer-Pipelines, jede enthält eine Integer-Ausführungseinheit und eine Adress-Erzeugungseinheit ; drei Fließkomma- und Multimedia-Pipelines Lade-/Speichereinheit mit jeweils zwei Lade/Speicheroperationen / Takt ergibt 72 Mikrooperationen die umgeordnet gleichzeitig ausführbar sind WS 2012/ Folie 69

70 2.3 Beispiele für Multikern-Architekturen AMD-Magny-Cours Opteron-Architektur Cache-Architektur separate L1 Instruktions- und Daten-Caches à 64 KBytes 2-fach assoziativ (load-to-use) Latenz von drei Taktzyklen on-chip L2 Cache mit 512 KBytes 16-fach assoziativ Latenz von 12 Zyklen im besten Fall Alle Caches entlang der Hierarchie (einschließlich L3 Cache) weisen 64-Byte große Cachezeilen auf WS 2012/ Folie 70

71 2.3 Beispiele für Multikern-Architekturen AMD-Magny-Cours Opteron-Architekturen Nachladen vom DRAM (system fills) und weiter hinter angeordneten Caches (L2 sowieso, aber auch L3 und evtl. L4) gehen direkt in L1 Cache Verdrängen des vorhandenen L1 Eintrags in L2 Cache (victim cache) Typischerweise erfolgt kein direkter Eintrag im L2 Cache Gemeinsamer L3 Cache übernimmt zwei Aufgaben übliche Cache-Funktion mit integriert Verzeichnis-Protokoll (probe filter oder Hyper-Transport Assist (HT Assist) bei AMD genannt) für Cache-Kohärenz Verzeichnis-Protokolle (zentral) Snoopy-Protokolle (MESI) lokal (s. Kap. 1, S. 171) WS 2012/ Folie 71

72 2.3 Beispiele für Multikern-Architekturen AMD-Magny-Cours Opteron-Architekturen Cache-Kokärenz in Multiprozessorsystemen besonderes Problem HT-Assist Directory-(Verzeichnis)-Protokoll Gleiches Ziel wie bei Forward-MESIF-Erweiterung bei Intel Probe or snoop filter -> soll Snoop -Anfragen reduzieren Benötigt 1 MB des 6 MB großen L3 Cache Folgendes Beispiel direkt entnommen aus P.Conway et.al.: CACHE HIERARCHY AND MEMORY SUBSYSTEM OF THE AMD OPTERON PROCESSOR, IEEE Computer, March/April WS 2012/ Folie 72

73 2.3 Beispiele für Multikern-Architekturen AMD-Magny-Cours Opteron-Architektur HT Assist (1) CPU 3 needs a cache line which CPU 1 has access to. The most recent data is however in CPU s 2 L2-cache. WS 2012/ Folie CPU 3 requests information from CPU 1 (blue data request arrow in diagram) 2. CPU 1 broadcasts to see if another CPU has more recent data (three red probe request arrows in diagram) 3. CPU 3 sits idle while these probes are resolved (four red & white probe response arrows in diagram) 4. The requested data is sent from CPU 2 to CPU 3 (two blue and white data response arrows in diagram) Two serious problems with this broadcasting approach. Firstly, it wastes a lot of bandwidth as 10 transactions are needed. Secondly, those 10 transactions are adding a lot of latency to the instruction on CPU 3

74 2.3 Beispiele für Multikern-Architekturen AMD-Magny-Cours Opteron-Architektur HT Assist (2) 1 MB des Caches wird für globales Verzeichnis verwendet Zeichnet auf, wo eine Cachezeile sich noch befindet 1. CPU 3 requests information from CPU 1 (blue line) 2. CPU 1 checks its L3 directory cache to locate the requested data (Fat red line) 3. The read from CPU 1 s L3 directory cache indicates that CPU 2 has the most recent copy and directly probes CPU 2 (Dark red line) 4. The requested data is sent from CPU 2 to CPU 3 (blue and white lines) Instead of 10 transactions, 4 this time. Reduction in latency and wasted bandwidth Probe broadcasting can be eliminated in 8 of 11 typical CPU-to-CPU transactions. Stream measurements show memory bandwidth improves 60%: 41.5 GB/s with HT Assist versus 25.5 GB/s without HT Assist. WS 2012/ Folie 74

75 2.3 Beispiele für Multikern-Architekturen AMD-Bulldozer Mikroarchitektur Übersicht Bulldozer Mikroarchitektur Multithreading-Architektur Basis: Bulldozer-Modul Dedizierte Thread-Komponenten Gemeinsame Komponenten, benutzt von mehreren Threads Mehrere on-chip Module definieren Multikern-Prozessor 4- und 8-Kern Variante AMD zählt Integerkerne als eigenständige Kerne (m.e. missverständlich) Konzept: Core-Multithreading WS 2012/ Folie 75

76 2.3 Beispiele für Multikern-Architekturen AMD-Bulldozer Mikroarchitektur Was heißt CMT? Bei Intel HT: Register und PC/PSW pro Thread vervielfältigt Bei CMT Mehrere Thread-spezifische (single thread) und Thread-gemeinsame Komponenten (vertical multithreading) und konkurrierend genutzte Komponenten (SMT / thread agnostic) WS 2012/ Folie 76

77 2.3 Beispiele für Multikern-Architekturen AMD-Bulldozer Mikroarchitektur Konzept des CMT (Core Multithreading) Einordbar zwischen SMT / HT und physikalischer Kern- Vervielfachung Quelle: basierend auf Angaben der Hersteller Ansatz Chip- Multiprozessor Core- Multithreading Hyperthreading Beispiel Dual-Core Bulldozer-Modul Sandy-Bridge-Kern Hardware-Overhead (gemessen an einem echten Kern) Performance-Vorteil (gegenüber einem echten Kern) Performance-Vorteil vs. Hardware- Overhead 2x etwa 1,20x < 1,05x bis zu 2x bis zu 1,8x bis zu 1,25x max. 1 max. 1,5 max. 1,2 WS 2012/ Folie 77

78 2.3 Beispiele für Multikern-Architekturen AMD-Bulldozer Mikroarchitektur Bulldozer Gesamtarchitektur (detailliert) WS 2012/ Folie 78

79 2.3 Beispiele für Multikern-Architekturen AMD-Bulldozer Mikroarchitektur Besonderheiten der Bulldozer Mikroarchitektur Entkopplung Sprungvorhersage und Befehlsholstufe über zwei Thread-spezifische Vorhersage-Puffer Vereinfacht zeitkritische Datenpfade zwischen dem Sprungvorhersageblock und dem Befehlsvorhersage-Block WS 2012/ Folie 79

80 2.3 Beispiele für Multikern-Architekturen AMD-Bulldozer Mikroarchitektur Vorhersage-Puffer wird von Sprungvorhersage mit Zeigern auf künftige auszuführende Befehle gefüllt Befehlshollogik verarbeitet diese Zeiger Holt Befehl aus L1-Cache bzw. L2-/L3-Cache oder Speicher Bei Cache-Instruktions-Fehlzugriff werden weitere Tags zukünftiger Sprungbefehle ermittelt und überprüft ob diese im Cache sind Zeitlich überlapptes Arbeiten von Sprungvorhersage und Befehlsholen Erlaubt Situationen zu erkennen, dass später benötigte Befehle noch nicht im L1-Cache werden im Voraus in L1-Instruktions-Cache geladen werden (Prefetching) WS 2012/ Folie 80

81 2.3 Beispiele für Multikern-Architekturen AMD-Bulldozer Mikroarchitektur Besonderheiten der Bulldozer Mikroarchitektur Entkopplung Sprungvorhersage und Befehlshol-Stufe FPU kann komplett über 256-Bitbreite von einem Thread genutzt werden, wenn anderer Thread sie nicht braucht Gilt auch für Komponenten der Frontende-Pipeline (Dekodiereinheit, Befehlsholeinheit, Sprungvorhersage etc.) Koalesker Write-through L1 Cache Pufferung von Schreibzugriffen von L1 auf L2 erlaubt höheren Durchsatz WS 2012/ Folie 81

82 2.4 Heterogene Multikern-Architekturen GPGPU General Purpose Graphics Processing Unit Eine kurze Geschichte der Grafikkarten ursprünglich: Graphics Card steuert Monitor an Mitte 80er: Grafikkarten mit 2D-Beschleunigung angelehnt an Arcade- und Home-Computer frühe 90er: erste 3D-Beschleunigung: Matrox Mystique, 3dfx Voodoo Rastern von Polygonen WS 2012/ Folie 82

83 2.4 Heterogene Multikern-Architekturen GPGPU Einführung Eine kurze Geschichte der Graphikkarten ursprünglich keine einheitliche Programmierschnittstelle herstellerspezifische Lösungen (3dfx Glide bzw. Matrox Simple Interface) Anfang der 90er: OpenGL etabliert in professionellem Umfeld Microsofts Direct3D zunächst unterlegen gewinnt Marktanteile dank häufiger Verbesserungen Ende der 90er: Grafikkarten übernehmen Koordinaten-Transformation und Beleuchtung (z.b. NVIDIA GeForce 256) Begriff Graphics Processing Unit wird erfunden WS 2012/ Folie 83

84 2.4 Heterogene Multikern-Architekturen GPGPU Einführung 2000er: zunächst nur Fixed-Function-Pipeline (FFP) Shader-Programme bieten mehr Flexibilität als FFP Pixel-Shader modellieren Oberflächen Vertex-Shader modifizieren Gitterpunkte Shader-Programme ursprünglich nur einfache Listen 2002: ATI Radeon 9700 kann Loops in Shadern ausführen Heute: Shader turing-vollständig Hersteller: ATI und NVIDIA Massenmarkt niedrige Preise WS 2012/ Folie 84

85 2.4 Heterogene Multikern-Architekturen GPGPU Einführung Zusammenfassung historische Entwicklung VGA Controller Memory Controller Display Generator GPU (Graphics Processing Unit) bearbeitet traditionelle Graphik-Pipeline in einem Chip zunächst weitgehend festverdrahtet GPGPU (General Purpose Graphics Processing Unit) programmierbare Prozessoren ersetzen feste Funktionsblöcke Berechnungen mit immer höherer Genauigkeit Index-Arithmetik Integer Single-Precision Double-Precision erweitert um allgemeine Prozessor-Instruktionen und eigenem Speicher parallele Programmierumgebungen CUDA WS 2012/ Folie 85

86 2.4 Heterogene Multikern-Architekturen GPGPU Einführung Entstanden Heterogenes Multiprozessor-System Massiv-parallele Vielkern-GPU (noch) Multikern-CPU Aktuelle Konfigurationen (s. rechts) Mittlerweile auch bei Intel Teile der NorthBridge in der CPU (s. Nehalem) GPU und CPU können, mit geringerer Bandbreite als ihre eigenen Speicher, jeweils die Speicher des anderen ansprechen Unified memory architecture Low-cost Variante kein eigener GPU-Speicher WS 2012/ Folie 86

87 2.4 Heterogene Multikern-Architekturen GPGPU Einführung Logische Graphik Pipeline Shader Programm, das Schattierungen vornimmt Auf Knotenpunkte (Vertex), auf Geometrische Primitive (Vertexes, die Geraden, Dreiecke, zusammenfassen) und einzelnen Bildpunkten Blaue Einheiten programmierbar, weiße fest verdrahtet Texturen beschreiben Oberflächeneigenschaften von Punkten von interpolierten Fließkomma-Koordinaten häufig in 1D, 2D- oder 3D-Feldern abgelegt WS 2012/ Folie 87

88 2.4 Heterogene Multikern-Architekturen GPGPU Einführung Beispiel Microsofts Direct3D 10 Pipeline Logische Pipeline abgebildet auf physikalischen Prozessor Blaue Einheiten nun durch Programm (Threads) realisierbar WS 2012/ Folie 88

89 2.4 Heterogene Multikern-Architekturen GPGPU Architektur Allgemeiner Aufbau GPGPU WS 2012/ Folie 89

90 2.4 Heterogene Multikern-Architekturen GPGPU Architektur Eigenschaften von GPGPUs viele, aber einfache Cores keine Sprungvorhersage etc. gruppiert in Multi-Prozessoren (Vektorprozessoren) Probleme bei nicht einheitlichen Sprüngen viele Register großer globaler Speicher Bandbreite: >100 GB/s Latenz: ~400 Taktzyklen kleine, schnelle on-chip Shared-Memory-Blöcke WS 2012/ Folie 90

91 2.4 Heterogene Multikern-Architekturen GPGPU Architektur Allgemeines Architekturschema einer Multithread-fähigen sog. Streaming Multiprozessoreinheit (SM) WS 2012/ Folie 91

92 2.4 Heterogene Multikern-Architekturen GPGPU Architektur Aufbau realer GPGPU- NVIDIA GeForce Streaming-Prozessoren (SP) organisiert in 14 Streaming- Multiprozessoren (SM) WS 2012/ Folie 92

93 2.4 Heterogene Multikern-Architekturen GPGPU Architektur Speicherhierarchie (Speicherräume) einer GPU: Globaler Speicher Untergebracht im externen DRAM Gleich aufgeteilt in SMs zugewiesenen Adressräumen Nicht explizit zugreifbar von CUDA-Programm zu einem Zeitpunkt nur ein Thread zugreifbar Gemeinsamer Speicher Untergebracht in SM-spezifischen SRAM-Bänken SM-spezifisch Gekoppelt an Thread-Block (s. später) WS 2012/ Folie 93

94 2.4 Heterogene Multikern-Architekturen GPGPU Architektur Lokaler Speicher Thread-spezifisch im SM-externen DRAM untergebracht Ausgleich Performanz-Verlust: Caching im gemeinsamen SM-Speicher dieser konfigurierbar Spezielle Speicher Texturen Konstanten Beides sind Konstantenspeicher, die zu Beginn einer Berechnung auf der Grafikkarte von der CPU beschreibar sind WS 2012/ Folie 94

95 2.4 Heterogene Multikern-Architekturen GPGPU Architektur Hardware-Details: NVIDIA G80 NVIDIA G80 Multiprozessor Vektorprozessor beinhaltet: 8 Shader: Single-Precision-Float- und Integer-Rechenwerk 1 Double Precision Unit (DPU) 2 Special Function Units (SFU) Sinus etc Register 16 KB Shared Memory WS 2012/ Folie 95

96 2.4 Heterogene Multikern-Architekturen GPGPU Architektur Hardware-Details: NVIDIA GT100 (a.k.a. Fermi) Vektorprozessor, beinhaltet: 32 Shader: Integer-Rechenwerk und Single-Precision-Float oder Double Precision mit halber Geschwindigkeit 16 Load-/Store-Units 4 Special Function Units (SFU) Sinus etc. 64 KB Shared Memory/Cache Aufteilbar in Cache für einzelne Threads und Gemeinsamen speicher für alle SP 32K Register WS 2012/ Folie 96

97 2.4 Heterogene Multikern-Architekturen GPGPU Architektur Speicherhierarchie: Register (am schnellsten) Shared Memory/L1 Cache entweder 16 KB Cache und 48 KB SM oder 48 KB Cache und 16 KB SM L2 Cache 768 KB ca. 260 GB/s Bandbreite DRAM 1-6 GB ca. 130 GB/s Bandbreite Latenz ca. 400 Takte WS 2012/ Folie 97

98 2.4 Heterogene Multikern-Architekturen GPGPU CUDA-Programmiermodell CUDA unterstützt ein Thread-paralleles und Daten-paralleles Programmierparadigma Jedoch Unterschied zu anderen Thread-parallelen Zerlegungen Alle Threads müssen die gleichen Operationen ausführen In diesem Sinne: Datenparallelität Nvidia bezeichnet dies als: SIMT (Single Instruction Multiple Threading) Möglich ist jedoch Wechsel von Threads genauer ganzen Thread-Feldern während einer Applikation WS 2012/ Folie 98

99 2.4 Heterogene Multikern-Architekturen GPGPU CUDA-Programmiermodell Veranschaulichung: Datenparallelität 2D/3D-Feld (Data-Grid) in Blöcke partitionieren Jeder Block enthält einzelne nicht weiter zerlegbare Elemente Auf jedem Element die gleiche Operation anwenden Bearbeitung verschiedener Felder zeitlich nacheinander möglich WS 2012/ Folie 99

100 2.4 Heterogene Multikern-Architekturen GPGPU CUDA-Programmiermodell Übertragen auf Threads und kooperative Thread-Felder Dieses und folgende Bilder entnommen aus: Nvidia Programming Guide Vers , 2009 WS 2012/ Folie 100

101 2.4 Heterogene Multikern-Architekturen GPGPU CUDA-Programmiermodell Übertragen auf Threads und kooperative Thread-Felder WS 2012/ Folie 101

102 2.4 Heterogene Multikern-Architekturen GPGPU CUDA-Programmiermodell CUDA Programmierung in C Function-Offloading: einzelne Funktionen laufen auf GPGPU (Kernels) bzw. CPU spezieller Compiler (nvcc) separiert Code drei Funktionstypen: host laufen auf CPU device laufen auf GPGPU global laufen auf GPGPU (können aber nur von CPU aufgerufen werden) drei Speichertypen: normaler Speicher im CPU-RAM device im RAM der GPGPU shared im Shared-Memory auf den Multi-Prozessoren WS 2012/ Folie 102

103 2.4 Heterogene Multikern-Architekturen GPGPU CUDA-Programmiermodell Darstellung zeitlicher Ablauf eines CUDA-Programms Heterogene Programmierung Serieller Kode läuft auf der CPU Paralleler Kode läuft auf der GPU Dimension von Grid und Thread-Blöcken wählbar dim3 dimblock0(1,12) ; dim3 Grid0(2,3) ; Kernel0<<<dimGrid0,dimBlock0>>>(,, ); bzw. dim3 dimblock1(1,9); dim3 Grid1(3,2); Kernel0<<<dimGrid,1dimBlock1>>>(,, ); WS 2012/ Folie 103

104 2.4 Heterogene Multikern-Architekturen GPGPU CUDA-Programmiermodell Cuda Memory Management CUDA-API-Aufrufe: Allokation/Deallokation von GPGPU-RAM Transfer CPU-RAM <-> GPGPU-RAM cudamalloc(, ) ; cudamemcpy(,, cudamemcpydevicetohost) ; cudamemcpy(,, cudamemcpyhosttodevice) ; (CUDA)-Kernels: Transfer GPGPU-RAM <-> Shared-Memory shared float As[BLOCK_SIZE] ; As[row] = GetElement(...,...) ; WS 2012/ Folie 104

105 2.4 Heterogene Multikern-Architekturen GPGPU CUDA-Programmierung 1. CUDA - Programmbeispiel: Hello World WS 2012/ Folie 105

106 2.4 Heterogene Multikern-Architekturen GPGPU CUDA-Programmierung CUDA: Hello World: WS 2012/ Folie 106

107 3. Architektur von Hochleistungsprozessoren 3.3 GPGPUs CUDA-Programmierung CUDA: Vektor-Addition-Beispiel Kode für GPU // Device code global void VecAdd(float* A, float* B, float* C) { int i = blockdim.x * blockidx.x + threadidx.x; } if (i < N) C[i] = A[i] + B[i]; WS 2012/ Folie 107

108 2.4 Heterogene Multikern-Architekturen GPGPU CUDA-Programmierung CUDA: Vektor-Addition-Beispiel Kode für CPU // Host code int main(){ int N =...; size_t size = N * sizeof(float); // Allocate input vectors h_a and h_b in host memory float* h_a = malloc(size); float* h_b = malloc(size); // Allocate vectors in device memory float* d_a, d_b, d_c; cudamalloc((void**)&d_a, size); cudamalloc((void**)&d_b, size); cudamalloc((void**)&d_c, size); // Copy vectors from host memory to device memory cudamemcpy(d_a, h_a, size, cudamemcpyhosttodevice); cudamemcpy(d_b, h_b, size, cudamemcpyhosttodevice); WS 2012/ Folie 108

109 2.4 Heterogene Multikern-Architekturen GPGPU CUDA-Programmierung CUDA: Vektor-Addition-Beispiel Kode für CPU // Invoke kernel int threadsperblock = 256; int blockspergrid = (N + threadsperblock 1) / threadsperblock; VecAdd<<<blocksPerGrid, threadsperblock>>>(d_a, d_b, d_c); // Copy result from device memory to host memory // h_c contains the result in host memory cudamemcpy(h_c, d_c, size, cudamemcpydevicetohost); // Free device memory cudafree(d_a); cudafree(d_b); cudafree(d_c); } WS 2012/ Folie 109

110 2.4 Heterogene Multikern-Architekturen GPGPU Fortgeschrittene CUDA-Programmierung Thread-Scheduling: Kernel = Funktion auf Grafikkarte viele Threads um Parallelität der GPGPU zu nutzen und Speicherlatenz zu verdecken wie gezeigt: Threads gruppiert in Blöcken Thread-Blöcke gruppiert in Grid Grid und Blöcke können 1D bis 3D sein Thread-IDs: Koordinaten blockidx, threadidx. WS 2012/ Folie 110

111 2.4 Heterogene Multikern-Architekturen GPGPU Fortgeschrittene CUDA-Programmierung Thread-Scheduling: Thread-Blöcke werden auf Multiprozessoren verteilt Multiprozessoren brechen Blöcke in Warps auf Warps = kleinere Thread-Gruppen (meist 32 Threads) alle Threads eines Warps: quasi-parallele Ausführung Problem bei divergenten Branches: serielle Abarbeitung WS 2012/ Folie 111

112 2.4 Heterogene Multikern-Architekturen GPGPU Thread-Scheduling Ablaufplanung? SIMT multithreaded warp scheduling Single Instruction Multiple Thread Eine Instruktion wird auf mehrere parallel ausgeführte und unabhängige Threads verteilt Warp Mehrere Threads werden zu einem sog. Warp zusammengefasst Z.B. 32 Threads in Warp ausgeführt auf den 8 SPs der GPU In jedem SP werden exakt 4 Threads ausgeführt Alle SPs arbeiten parallel zueinander, die 4 Threads werden in 4 Takten nacheinander ausgeführt WS 2012/ Folie 112

113 2.4 Heterogene Multikern-Architekturen GPGPU Thread-Scheduling Ablaufplaner wählt einen Warp zur Ausführung aus Verbreitet an alle aktiven Threads synchron die gleiche Instruktion Nicht jeder Thread braucht seinen eigenen Programmkodespeicher Aktive und inaktive Threads Threads können aufgrund von Verzweigungen (if-then-else) verschiedene Zweige nehmen SIMT-Architektur vereint Thread- und Daten- Parallelismus Mehrere Threads laufen parallel Einzelne Threads haben eigene Datenbereiche SP Register werden unter Threads gleichmäßig aufgeteilt WS 2012/ Folie 113

114 2.4 Heterogene Multikern-Architekturen GPGPU Thread-Scheduling Thread-Scheduling Problem-Zerlegung: viele Blöcke alle Multiprozessoren beschäftigt viele Threads je Block Speicherlatenz verdecken aber: je weniger Threads je Block, desto mehr Shared Memory je Thread verfügbar Daumenregel: doppelt so viele Blöcke wie Multiprozessoren 256 Threads je Block Praxis: viel Experimentieren notwendig um optimale Aufteilung zu finden WS 2012/ Folie 114

115 2.4 Heterogene Multikern-Architekturen GPGPU Thread-Scheduling Speicherzugriff Thread mit Nummer x im Warp Aligned: Thread x greift auf Adresse 128 k + 4 x zu Coalescing: Alle Zugriffe eines Warps können in eine Transaktion von 128 Byte zusammengefasst werden Coalescing bringt beste Performance, benötigt meist Alignment alte GPUs (Compute Capability 1.0 bzw. 1.1) ineffizienter als neue (Compute Capability 1.2) Bei Schreiben auf selbe Adresse: Warp Serialize (serielle Ausführung der Threads eines Warps) WS 2012/ Folie 115

116 2.4 Heterogene Multikern-Architekturen GPGPU Thread-Scheduling Speicherzugriff: Coalescing, Compute Capability 1.1 k-ter Thread greift auf k-tes Wort in 128-Byte-Segment zu, nicht alle Threads müssen teilnehmen. OK, 1 Transaktion: Out of Sequence, 16 Transaktionen: Misaligned, 16 Transaktionen: WS 2012/ Folie 116

117 2.4 Heterogene Multikern-Architekturen GPGPU Fortgeschrittene CUDA-Programmierung Speicherzugriff: Coalescing, Compute Capability 1.2 Transaktionen können 32, 64 oder 128 Byte groß sein, kleinere Transaktionen um Bandbreite zu sparen. 1 Transaktion, 64 Byte: 2 Transaktionen, 64 bzw. 32 Byte: 1 Transaktion, 128 Byte: WS 2012/ Folie 117

118 2.4 Heterogene Multikern-Architekturen GPGPU Fortgeschrittene CUDA-Programmierung Speicherzugriff Kopiert Vector src nach dst Offset verschiebt Alignment bei falschem Alignment kein Coalescing daher schlechter Durchsatz WS 2012/ Folie 118

119 2.4 Heterogene Multikern-Architekturen GPGPU Fortgeschrittene CUDA-Programmierung Beispiel: Matrix-Multiplikation Scheinbar einfache Aufgabe, häufig Teilproblem beim wissenschaftlichen Rechnen Beispiele: Computergrafik Optik Matrizenmechanik Schwierigkeit: wenig Berechnung aber viel Speicherzugriff Ziel: Speicherzugriffe so organisieren, dass maximale Bandbreite erreicht wird. WS 2012/ Folie 119

120 2.4 Heterogene Multikern-Architekturen GPGPU Fortgeschrittene CUDA-Programmierung Beispiel: Matrix-Multiplikation Folgende Beispiele: Multiplikation von float-matrizen Dimension: 1024 x 1024 gemessene Zeiten gelten für eine Matrix-Multiplikation Hardware: NVIDIA GeForce GTS 250 Performance-Unterschiede: 2 Größenordnungen WS 2012/ Folie 120

121 2.4 Heterogene Multikern-Architekturen GPGPU Fortgeschrittene CUDA-Programmierung Matrix-Multiplikation: naiver Algorithmus Zeit: 1.032s Probleme: Matrizen werden mehrfach ausgelesen kaum Coalescing beim Speicherzugriff WS 2012/ Folie 121

122 2.4 Heterogene Multikern-Architekturen GPGPU Fortgeschrittene CUDA-Programmierung Matrix-Multiplikation: transponiert Erwartung: Matrix B ist transponiert gegeben Zeit: 1.415s ~40% langsamer Gegensatz: CPUs sind mit diesem Algorithmus schneller WS 2012/ Folie 122

123 2.4 Heterogene Multikern-Architekturen GPGPU Fortgeschrittene CUDA-Programmierung Matrix-Multiplikation: Texture Caching Matrizen A und B über Texture-Units lesen (Caching), Zeit: 0.046s, ~20 schneller. Problem: Textur-Caches haben begrenzte Größe, daher werden nicht alle Zugriffe gecachet. WS 2012/ Folie 123

124 2.4 Heterogene Multikern-Architekturen GPGPU Fortgeschrittene CUDA-Programmierung Matrix-Multiplikation: Shared Memory WS 2012/ Folie 124

125 2.4 Heterogene Multikern-Architekturen GPGPU Fortgeschrittene CUDA-Programmierung Matrix-Multiplikation: Shared Memory Matrizen kachelweise lesen/schreiben on-chip Shared Memory dient als schneller Puffer Synchronisation wichtig Schleife: Beide Kacheln lesen Synchronisation Kachelstreifen multiplizieren Synchronisation Zeit: 0.018s ~55 x schneller Problem: Bank Conflicts bei Shared Memory WS 2012/ Folie 125

126 2.4 Heterogene Multikern-Architekturen GPGPU Zusammenfassung GPGPUs haben viele, aber einfach gestaltete Cores Programmierung mittels Function-Offloading sehr viele Threads wegen Parallelität und Latenz vom GPGPU-RAM Threads sind in Blöcken zusammengefasst Blöcke sind im Grid zusammengefasst on-chip Shared Memory dient als schneller Zwischenspeicher Transfer CPU-RAM zu GPGPU-RAM via API-Funktionen WS 2012/ Folie 126

127 2.4 Heterogene Multikern-Architekturen Ausblick: Vielkernarchitekturen Intels SCC Intels Single Cloud Chip (SCC) Vielkern-CPU besteht aus 24 Dual-IA(Intel Architecture)-Kern Kacheln (tiles), somit 48 Kerne Verbunden über ein 2D-Gitter on-chip -Netzwerk Quelle: regmedia.co.uk/2009/ 12/02/intel_scc.jpg WS 2012/ Folie 127

128 2.4 Heterogene Multikern-Architekturen Ausblick: Vielkernarchitekturen Intels SCC Physikalische Eigenschaften des Chips 45 nm high-k CMOS Technologie, 1.3 Milliarden Transistoren Fläche einer Kachel 18 mm 2, gesamter Chip 567 mm 2 Elektrische Leistungsaufnahme des gesamten Chips reicht von 25 bis 125 Watt 25 W bei 0.7 V, 125 MHz pro Kern, 250 MHz für Netz und 50 C 125 W bei 1.14 V, 1 GHz pro Kern, 2 GHz für Netz und 50 C Leistung für on-die Netzwerk 6 W bei 1.5 Tb/s Bisektions-Bandbreite 12 W bei 2 Tb/s Biseketions-Bandbreite WS 2012/ Folie 128

129 2.4 Heterogene Multikern-Architekturen Ausblick: Vielkernarchitekturen Intels SCC Kacheln aufgebaut als 6x4-Netz Jede Kachel enthält zwei Blöcke jeweils mit einem P54C Kern, 16 KB Befehls- und Datencache, 256 KB einheitlicher L2 Cache WS 2012/ Folie 129

130 2.4 Heterogene Multikern-Architekturen Ausblick: Vielkernarchitekturen Intels SCC Mesh Interface Unit (MIU) Schaltkreis um Netz und Schnittstelle mit verschiedenen Frequenzen zu betreiben Router Ein 16 KB Message Passing Buffer Für die Kommunikation zwischen den Kernen Zwei test-and-set Register Cache-Controller (CC) Verbindet Kacheln miteinander Anschluss an PCIe-Bus für Programmierplattform auf Host Vier DDR3-RAM Speicherkontroller WS 2012/ Folie 130

131 2.4 Heterogene Multikern-Architekturen Ausblick: Vielkernarchitekturen Intels SCC SCC Speicherarchitektur Privater mit jedem Kern verbundener off-chip Speicher gemeinsamer off-chip DRAM Gemeinsamer on-chip SRAM (MPB Message Passing Buffer) WS 2012/ Folie 131

132 2.4 Heterogene Multikern-Architekturen Ausblick: Vielkernarchitekturen Intels SCC Cache-Kohärenz In der Verantwortung des Programmierers Test-and-Set Register dafür nutzbar Erlaubt Sperren von Zugriffen Abfragen zur Synchronisierung bei Zugriff S. folgendes Beispiel L1 Cache-Daten ungültig setzen wenn Daten in MP-Puffer Möglich mit Kommando CL1INVMB WS 2012/ Folie 132

133 2.4 Heterogene Multikern-Architekturen Ausblick: Vielkernarchitekturen Intels SCC SCC Communication Environment (RCCE) RCCE verwendet statisches SPMD (single program multiple data)-modell Jeder Kern gleiches Programm Kern-spezifische Unterschiede anhand eindeutiger Prozessor-Kern- Identität festlegen WS 2012/ Folie 133