MESIF- (links) vs. MESI-Protokoll (rechts)

2.3 Beispiele für Multikern-Architekturen 2.3.1 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/14 28.11.2013-19.12.2013 Folie 53

2.3 Beispiele für Multikern-Architekturen 2.3.1 Intel-Nehalem-Architektur Nehalem-Modelle im Vergleich WS 2013/14 28.11.2013-19.12.2013 Folie 54

2.3 Beispiele für Multikern-Architekturen 2.3.2 Intel Sandy-Bridge-Architektur Nehalem/Westmere im Vergleich zu Sandy Bridge Quelle Bilder/Informationen: www.ht4u.net 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/14 28.11.2013-19.12.2013 Folie 55

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

2.3 Beispiele für Multikern-Architekturen 2.3.2 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. 2008 / März 2010 Sep. 2009 Jan. 2010 Jan. 2011 Feb. 2009 Sockel 775 1366 1156 1156 1155 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 107 275 / 248 296 81 + 114 131 bis 216 max. 258 / 346 Transistoren [Mio] max. TDP [Watt] 820 731 / 1170 774 383 + 177 504 bis 995 max. 758 / 904 130 130 95 87 95 140 WS 2013/14 28.11.2013-19.12.2013 Folie 57

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

2.3 Beispiele für Multikern-Architekturen 2.3.2 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 2013/14 28.11.2013-19.12.2013 Folie 59

2.3 Beispiele für Multikern-Architekturen 2.3.2 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/14 28.11.2013-19.12.2013 Folie 60

2.3 Beispiele für Multikern-Architekturen 2.3.2 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/14 28.11.2013-19.12.2013 Folie 61

2.3 Beispiele für Multikern-Architekturen 2.3.2 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/14 28.11.2013-19.12.2013 Folie 62

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

2.3 Beispiele für Multikern-Architekturen 2.3.3 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 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 WS 2013/14 28.11.2013-19.12.2013 Folie 64

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/14 28.11.2013-19.12.2013 Folie 65

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/14 28.11.2013-19.12.2013 Folie 66

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/14 28.11.2013-19.12.2013 Folie 67

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/14 28.11.2013-19.12.2013 Folie 68

2.4.1 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 2013/14 28.11.2013-19.12.2013 Folie 69

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/14 28.11.2013-19.12.2013 Folie 70

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/14 28.11.2013-19.12.2013 Folie 71

2.4.1 GPGPU Architektur Allgemeiner Aufbau GPGPU WS 2013/14 28.11.2013-19.12.2013 Folie 72

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/14 28.11.2013-19.12.2013 Folie 73

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

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

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/14 28.11.2013-19.12.2013 Folie 76

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/14 28.11.2013-19.12.2013 Folie 77

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. 4096 Register 16 KB Shared Memory WS 2013/14 28.11.2013-19.12.2013 Folie 78

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/14 28.11.2013-19.12.2013 Folie 79

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/14 28.11.2013-19.12.2013 Folie 80

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/14 28.11.2013-19.12.2013 Folie 81

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/14 28.11.2013-19.12.2013 Folie 82

2.4.1 GPGPU CUDA-Programmiermodell Übertragen auf Threads und kooperative Thread-Felder Dieses und folgende Bilder entnommen aus: Nvidia Programming Guide Vers. 2.3.1, 2009 WS 2013/14 28.11.2013-19.12.2013 Folie 83

2.4.1 GPGPU CUDA-Programmiermodell Übertragen auf Threads und kooperative Thread-Felder WS 2013/14 28.11.2013-19.12.2013 Folie 84

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/14 28.11.2013-19.12.2013 Folie 85

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

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] = GetElement(...,...) ; WS 2013/14 28.11.2013-19.12.2013 Folie 87

2.4.1 GPGPU CUDA-Programmierung 1. CUDA - Programmbeispiel: Hello World WS 2013/14 28.11.2013-19.12.2013 Folie 88

2.4.1 GPGPU CUDA-Programmierung CUDA: Hello World: WS 2013/14 28.11.2013-19.12.2013 Folie 89

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/14 28.11.2013-19.12.2013 Folie 90

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/14 28.11.2013-19.12.2013 Folie 91

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/14 28.11.2013-19.12.2013 Folie 92

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/14 28.11.2013-19.12.2013 Folie 93

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/14 28.11.2013-19.12.2013 Folie 94

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/14 28.11.2013-19.12.2013 Folie 95

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/14 28.11.2013-19.12.2013 Folie 96

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/14 28.11.2013-19.12.2013 Folie 97

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 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 2013/14 28.11.2013-19.12.2013 Folie 98

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/14 28.11.2013-19.12.2013 Folie 99

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/14 28.11.2013-19.12.2013 Folie 100

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/14 28.11.2013-19.12.2013 Folie 101

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/14 28.11.2013-19.12.2013 Folie 102

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/14 28.11.2013-19.12.2013 Folie 103

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/14 28.11.2013-19.12.2013 Folie 104

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/14 28.11.2013-19.12.2013 Folie 105

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/14 28.11.2013-19.12.2013 Folie 106

2.4.1 GPGPU Fortgeschrittene CUDA-Programmierung Matrix-Multiplikation: Shared Memory WS 2013/14 28.11.2013-19.12.2013 Folie 107

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/14 28.11.2013-19.12.2013 Folie 108

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/14 28.11.2013-19.12.2013 Folie 109