Intels Tick-Tock-Prinzip

Transkript

1 2.3 Beispiele für Multikern-Architekturen Von Intel-Nehalem- bis Haswell-Architektur Intels Tick-Tock-Prinzip Gleiche Mikroarchitektur und Prozess-Technologiesprung (Tick) Neue Mikroarchitektur (Tock) mit vorheriger Prozess-Technologie WS 2013/ Folie 39

2 2.3 Beispiele für Multikern-Architekturen Von Intel-Nehalem- bis Haswell-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 2013/ Folie 40

3 2.3 Beispiele für Multikern-Architekturen Von Intel-Nehalem- bis Haswell-Architektur Beispiel: Nehalem Quad-Core Prozessor WS 2013/ Folie 41

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

5 2.3 Beispiele für Multikern-Architekturen Von Intel-Nehalem- bis Haswell-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 2013/ Folie 43

6 2.3 Beispiele für Multikern-Architekturen Von Intel-Nehalem- bis Haswell-Architektur Turbo Boost Technologie (seit Nehalem) 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 (ab SandyBridge 100 MHz) 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 2 x 133 MHz WS 2013/ Folie 44

7 2.3 Beispiele für Multikern-Architekturen Von Intel-Nehalem- bis Haswell-Architektur Hyperthreading (schon seit Pentium-Prozessoren) 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 2013/ Folie 45

8 2.3 Beispiele für Multikern-Architekturen Von Intel-Nehalem- bis Haswell-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 2013/ Folie 46

9 2.3 Beispiele für Multikern-Architekturen Von Intel-Nehalem- bis Haswell-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 2013/ Folie 47

10 2.3 Beispiele für Multikern-Architekturen Von Intel-Nehalem- bis Haswell-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 2013/ Folie 48

11 2.3 Beispiele für Multikern-Architekturen Von Intel-Nehalem- bis Haswell-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 2013/ Folie 49

12 2.3 Beispiele für Multikern-Architekturen Von Intel-Nehalem- bis Haswell-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 2013/ Folie 50

13 2.3 Beispiele für Multikern-Architekturen Von Intel-Nehalem- bis Haswell-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 2013/ Folie 51

14 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 2013/ Folie 52

15 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 2013/ Folie 53

16 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Nehalem-Modelle im Vergleich WS 2013/ Folie 54

17 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 2013/ Folie 55

18 2.3 Beispiele für Multikern-Architekturen Intel Sandy-Bridge-Architektur Sandy-Bridge-Mikroarchitektur im Überblick WS 2013/ Folie 56

19 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 2013/ Folie 57

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

21 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. Folie 42 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 2013/ Folie 59

22 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 2013/ Folie 60

23 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ßen Registersatz und Zeiger in Pipelinestufen mitführen» Zeiger geringere Anzahl Bits -> spart Energie WS 2013/ Folie 61

24 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 2013/ Folie 62

25 2.3 Beispiele für Multikern-Architekturen Von Intel-Nehalem- bis Haswell-Architektur (Haswell) Einführung Transactional Memory TM in Haswell Vermeidung von blockierenden Code-Threads durch locks s. Bsp. Tafel Konflikte bei TM bei eager Detektion (s. Bsp. Tafel) lazy Detektion (s. Bsp. Tafel) WS 2013/ Folie 63

26 2.3 Beispiele für Multikern-Architekturen Von Intel-Nehalem- bis Haswell-Architektur (Haswell) TM in Haswell Hardware-Lock-Elision (HLE) Kompatibel mit alten Befehlen 2 neue Präfix-Instruktionen: XACQUIRE and XRELEASE Setzt Lock aus bei Haswell; Überprüfung bei XRELEASE bei anderen Prozessoren wird Präfix ignoriert und lock durchgeführt Restricted Transactional Memory (RTM) Nun explizite Befehle zur Abgrenzung von Transaktionen und Überprüfen ob Konflikt eingetreten ist XBEGIN, XEND und XABORT XTEST: überprüft ob Kode gerade Kode einer Transaktion ausführt Flexibler als HLE: erlaubt Programmierung einer Fallback -Routine im Fehlerfall WS 2013/ Folie 64

27 2.4.1 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 2013/ Folie 65

28 2.4.1 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 2013/ Folie 66

29 2.4.1 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 2013/ Folie 67

30 2.4.1 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 2013/ Folie 68

31 2.4.1 GPGPU Einführung Entstanden Heterogenes Multiprozessor-System Massiv-parallele Vielkern-GPU 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 2013/ Folie 69

32 2.4.1 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 2013/ Folie 70

33 2.4.1 GPGPU Einführung Beispiel Microsofts Direct3D 10 Pipeline Logische Pipeline abgebildet auf physikalischen Prozessor Blaue Einheiten nun durch Programm (Threads) realisierbar WS 2013/ Folie 71

34 2.4.1 GPGPU Architektur Allgemeiner Aufbau GPGPU WS 2013/ Folie 72

35 2.4.1 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 2013/ Folie 73

36 2.4.1 GPGPU Architektur Allgemeines Architekturschema einer Multithread-fähigen sog. Streaming Multiprozessoreinheit (SM) WS 2013/ Folie 74

37 2.4.1 GPGPU Architektur Aufbau realer GPGPU- NVIDIA GeForce Streaming-Prozessoren (SP) organisiert in 14 Streaming- Multiprozessoren (SM) WS 2013/ Folie 75

38 2.4.1 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 2013/ Folie 76

39 2.4.1 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 2013/ Folie 77

40 2.4.1 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 2013/ Folie 78

41 2.4.1 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 2013/ Folie 79

42 2.4.1 GPGPU Architektur Blockdiagramm Layout der Fermi-Architektur Entnommen aus Nvidia_Fermi_Computer_Architecture_WhitePaper.pdf Ablaufplanung / Verteilung (Scheduler / Dispatcher) Registerspeicher SM-Prozessor SP-Prozessor Load/Store- Units SFU-Prozessor L1 Cache / Shared Memory WS 2013/ Folie 80

43 2.4.1 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 2013/ Folie 81

44 2.4.1 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 2013/ Folie 82

45 2.4.1 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 2013/ Folie 83

46 2.4.1 GPGPU CUDA-Programmiermodell Übertragen auf Threads und kooperative Thread-Felder Dieses und folgende Bilder entnommen aus: Nvidia Programming Guide Vers , 2009 WS 2013/ Folie 84

47 2.4.1 GPGPU CUDA-Programmiermodell Übertragen auf Threads und kooperative Thread-Felder WS 2013/ Folie 85

48 2.4.1 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 2013/ Folie 86

49 2.4.1 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(12,1) ; dim3 Grid0(3,2) ; Kernel0<<<dimGrid0,dimBlock0>>>(,, ); bzw. dim3 dimblock1(9,1); dim3 Grid1(2,3); Kernel0<<<dimGrid,1dimBlock1>>>(,, ); WS 2013/ Folie 87

50 2.4.1 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] = h[...] ; // h Pointer to global memory WS 2013/ Folie 88

51 2.4.1 GPGPU CUDA-Programmierung 1. CUDA - Programmbeispiel: Hello World WS 2013/ Folie 89

52 2.4.1 GPGPU CUDA-Programmierung CUDA: Hello World: WS 2013/ Folie 90

53 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 2013/ Folie 91

54 2.4.1 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 2013/ Folie 92

55 2.4.1 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 2013/ Folie 93

56 2.4.1 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 2013/ Folie 94

57 2.4.1 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 2013/ Folie 95

58 2.4.1 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 2013/ Folie 96

59 2.4.1 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 2013/ Folie 97

60 2.4.1 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 2013/ Folie 98

61 2.4.1 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 Bei Schreiben auf selbe Adresse: Warp Serialize (serielle Ausführung der Threads eines Warps) WS 2013/ Folie 99

62 2.4.1 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 2013/ Folie 100

63 2.4.1 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 2013/ Folie 101

64 2.4.1 GPGPU Fortgeschrittene CUDA-Programmierung Speicherzugriff Kopiert Vector src nach dst Offset verschiebt Alignment bei falschem Alignment kein Coalescing daher schlechter Durchsatz WS 2013/ Folie 102

65 2.4.1 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 2013/ Folie 103

66 2.4.1 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 2013/ Folie 104

67 2.4.1 GPGPU Fortgeschrittene CUDA-Programmierung Matrix-Multiplikation: naiver Algorithmus Zeit: 1.032s Probleme: Matrizen werden mehrfach ausgelesen kaum Coalescing beim Speicherzugriff WS 2013/ Folie 105

68 2.4.1 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 2013/ Folie 106

69 2.4.1 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 2013/ Folie 107

70 2.4.1 GPGPU Fortgeschrittene CUDA-Programmierung Matrix-Multiplikation: Shared Memory WS 2013/ Folie 108

71 2.4.1 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 2013/ Folie 109

72 2.4.1 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 2013/ Folie 110

73 2.4.2 Ausblick Vielkernarchitekturen Paralella-Board der Fa. Adapteva Epihany-Parallel-Mulitcore (64 1 GHz RISC Prozessoren) + Zynq- FPGA-Plattform (Dual-Core ARM + GlueLogic) OpenSource Hardware Programmierbar in OpenCL WS 2013/ Folie 111