Prinzipieller Aufbau der Architektur eines Multikern- Prozessors. Programmierung Standard-Mulitkern-Prozessoren mit OpenMP

Transkript

1 3.1 Einführung Multi-Core-Architekturen Motivation Multikern-Prozessoren Prinzipieller Aufbau der Architektur eines Multikern- Prozessors Programmierung Standard-Mulitkern-Prozessoren mit OpenMP Programmierung von Grafikkern-Prozessoren unter CUDA WS 2013/14, Folie 1

2 3.1 Einführung Multi-Core-Architekturen Sprunghafter Anstieg der Leistung von Mikroprozessoren Verbesserte Organisation, verbesserte Architektur Erhöhte Taktfrequenz Mehr Parallelität Pipelining Superskalare Architekturen Simultanes Multithreading (SMT) Preis der höheren Parallelität Höhere Komplexität erfordert mehr Logik Ansteigende Chipfläche für die Organisation und Bedarf an Logik für Signalübertragung Schwieriger zu entwerfen, herzustellen und Fehler zu suchen (debugging) WS 2013/14, Folie 2

3 3.1 Einführung Multi-Core-Architekturen Grobe Skizzierung des Aufbaus der Architekturen Superskalar Simultanes Multithreading Multikern-Prozessor WS 2013/14, Folie 3

4 3.1 Einführung Multi-Core-Architekturen Anstieg Leistung Relativ zu Leistung einer Architektur von 1985 In Relation zur Taktfrequenz WS 2013/14, Folie 4

5 3.1 Einführung Multi-Core-Architekturen Anforderung: elektrische Leistung wächst exponentiell mit Schaltungsdichte auf Chip und Taktfrequenz WS 2013/14, Folie 5

6 3.1 Einführung Multi-Core-Architekturen Gegensteuern durch Verwendung Chipfläche für Cache Höhere Dichte möglich durch regulären Aufbau SRAM-Speicher Eine Größenordnung weniger Leistungsbedarf vs. Logik WS 2013/14, Folie 6

7 3.1 Einführung Multi-Core-Architekturen Schätzung bis 2015 (ca. 8 Jahre alt) 100 Milliarden Transistoren auf 300 mm² Chip-Die (Chip-Inneres) Cache der Größe 100 MB 1 Milliarde Transistoren für Logik WS 2013/14, Folie 7

8 3.1 Einführung Multi-Core-Architekturen Regel von Pollack Leistung ungefähr proportional zur Quadratwurzel des Anstiegs an Komplexität Doppelte Komplexität, d.h. doppelt so großer Einzelprozessor schafft nur 40% mehr Leistung Multikern-Technik hat prinzipielles Potential für nahezu lineare Verbesserung Unwahrscheinlich, dass ein einziger Thread den gesamten Cache effektiv nutzt Mehrere Threads nutzen mehrere Caches als einen einzigen riesig großen Cache besser aus WS 2013/14, Folie 8

9 3.1 Einführung Multi-Core-Architekturen Vorteile bei Leistung hängen effektiv von der Ausnutzung der parallelen Ressourcen ab Bereits geringe Anteile an seriellem Kode beeinflussen die Leistung 10% inhärenter serieller Anteil führt auf 8 Prozessorsystem nur zu 4,7-fachen Leistungsanstieg (Details s. später Kapitel 5) Weiterhin: Zusatzaufwand durch Parallelisierung Kommunikation Lastverteilung Einhalten der Cachekohärenz Bestimmte Anwendungen können Potential von Multikernprozessoren effektiv ausnutzen WS 2013/14, Folie 9

10 3.1 Einführung Multi-Core-Architekturen Beispiele: allgemein Serverrechner, die unabhängige Anfragen beantworten Datenbanken Native Multi-Thread und Multi-Prozess Applikationen Z.B. Lotus Domino, Siebel CRM, Oracle, SAP, PeopleSoft Java VM ist Multi-Thread-Lösung mit Ablaufplanung und Speichermanagement Sun s Java Application Server, BEA s Weblogic, IBM Websphere, Tomcat Mehrfache Instanziierungen einer Applikation Eine Applikation, die mehrfach läuft Single Program Multiple Data (SPMD) Inhärente Parallelität, z.b. Parameterstudien Details s. Kap. 5, Parallelisierungsstrategien WS 2013/14, Folie 10

11 3.1 Einführung Multi-Core-Architekturen Erreichbare Beschleunigung (Speedup) gegenüber einem Prozessor Für verschiedene Anzahl an Prozessoren Verschieden hohe serielle Anteile Ohne Berücksichtigung Overhead WS 2013/14, Folie 11

12 3.1 Einführung Multi-Core-Architekturen Mit Berücksichtigug Overhead WS 2013/14, Folie 12

13 3.1 Einführung Multi-Core-Architekturen Merkmale für Multikern-Architekturen Anzahl Prozessorkerne auf dem Chip Anzahl Cacheebenen auf dem Chip Anteil gemeinsamer Speicher Auf den nächsten Folien Beispiele: Intel Core Duo Intel Core i7 WS 2013/14, Folie 13

14 3.1 Einführung Multi-Core-Architekturen Verschiedene Varianten der Core-Cache-Anbindung Dedizierter vs. gemeinsamer Cache WS 2013/14, Folie 14

15 3.1 Einführung Multi-Core-Architekturen Intel Core Duo verwendete superskalare Kerne WS 2013/14, Folie 15

16 3.1 Einführung Multi-Core-Architekturen Stand superskalare x86 - Architekturen, gemeinsamer L2 Cache Dedizierter L1-Cache pro Kern 32 KB für Befehle und 32 KB für Daten Thermische Steuereinheit pro Kern Behandelt Hitzedissipation des Prozessorchips Maximiert Leistung unter Beachtung von Randbedingungen Verbesserte Ergonomie Advanced Programmable Interrupt Controller (APIC) Interprozess Unterbrechungen zwischen Kernen Verteilt Unterbrechung zu entsprechenden Kern Beinhaltet Timer-Komponente, so dass Betriebssystem den Kern unterbrechen kann WS 2013/14, Folie 16

17 3.1 Einführung Multi-Core-Architekturen Power Management Logic Zeigt thermische Bedingungen und CPU Aktivität an Regelt Spannung und damit Leistungsverbrauch Kann individuell logische Subsysteme zu- und abschalten Gemeinsamer 2 MB großer L2 Cache Dynamische Zuweisung MESI (ist ein Cache-Kohärenz-Protokoll, s ) Unterstützung für L1 Cache Wurde gegenüber früheren Lösungen erweitert um mehrere Duo- Kern-Architekturen beim Aufbau von symmetrischen Multiprozessoren (SMP) zu unterstützen gemeinsame L2 Daten zwischen lokalen Kernen oder externen Kernen geteilt WS 2013/14, Folie 17

18 3.1 Einführung Multi-Core-Architekturen Intel Core i7 verwendet simultanes Multi-Threading (SMT) Skaliert bis zur Anzahl unterstützter Threads 4 SMT Kerne, jeder unterstützt 2 Threads somit 8 logische Kerne WS 2013/14, Folie 18

19 3.1 Einführung Multi-Core-Architekturen November 2008 Vier x86 SMT Prozessorkerne Dedizierter L2, gemeinsamer L3 Cache Spekulative vorausschauendes Holen (pre-fetch) für Caches On chip DDR3 Speicherkontroller Drei 8 Byte Kanäle (192 Bits) mit insgesamt 32 GB/s Bandbreite Keinen Front Side Bus mehr QuickPath Verbindung Cache-kohärente Punkt-zu-Punkt-Verbindung Hochgeschwindigkeits-Verbindung zwischen Prozessorchips 6.4 x 10 9 Transfers pro Sekunde mit 16 Bits pro Transfer Dedizierter bi-direktionaler Kanal Gesamte Bandbreite: 25.6 GB/s WS 2013/14, Folie 19

20 3.1 Einführung Multi-Core-Architekturen OpenMP: Anwender-Programmierschnittstelle (API) für Speicher-gekoppelte Multiprozessoren Compiler-Direktiven Bibliothek unterstützender Funktionen OpenMP arbeitet in Verbindung mit Fortran, C, oder C++ Modell des gemeinsamen Speichers Synchronisation und Interaktion der Prozessoren untereinander durch gemeinsame Variablen Processor Processor Processor Processor Memory WS 2013/14, Folie 20

21 3.1 Einführung Multi-Core-Architekturen Fork/Join-Parallelismus zu Beginn nur Master-Thread aktiv Master-Thread führt sequentiellen Kode aus Fork: Master-Thread erzeugt oder erweckt zusätzliche Threads um parallelen Kode auszuführen Join: am Ende des parallelen Kodes sterben Threads bzw. werden ausgesetzt Master Thread Other threads fork Time join fork join WS 2013/14, Folie 21

22 3.1 Einführung Multi-Core-Architekturen Speicher-gekoppeltes Modell vs. Nachrichten-gekoppeltes Modell Speicherkopplung: (shared-memory model) Anzahl der aktiven Threads zu Beginn und am Ende des Programms 1 Anzahl ändert sich dynamisch während der Programmausführung Nachrichtenkopplung: (message-passing model) alle Prozesse sind während der Ausführung eines Programms aktiv WS 2013/14, Folie 22

23 3.1 Einführung Multi-Core-Architekturen Inkrementelle Parallelisierung inkrementelle Parallelisierung: Prozess des schrittweisen Übertragens eines seriellen Programms in ein paralleles Programm Speicher-gekoppeltes Modell Ausführen und Messen sequentielles Programm inkrementelles Parallelisieren Beenden wenn weiterer Aufwand nicht mehr lohnt Beispiel: OpenMP (Open Multiprocessing) Nachrichten-gekoppeltes Modell Übertragung sequentiell nach parallel erfordert mehr Aufwand, da Übertragung in einem großen statt in vielen kleinen Schritten erfolgt Beispiel: MPI (Message Passing Interface) WS 2013/14, Folie 23

24 3.1 Einführung Multi-Core-Architekturen Beispiel Parallelisierung von Schleifen in C Programm häufig in for-schleifen Datenparallelität gegeben for (i = 0; i < N; i++) a[i] = b[i] + c[i]; OpenMP verwendet möglichst einfachen Mechanismus um anzuzeigen, wann Iterationen einer Schleife parallel ausgeführt werden können Compiler generiert automatisch Kode, der weitere den Iterationen zugeordnete Threads durch Fork/Join-Operationen erzeugt Verwendung von pragma Compiler-Direktiven steht für pragmatische Information ( pragmatic information ) Möglichkeit der Kommunikation Programmierer und Compiler Compiler obliegt es Pragma-Anweisungen zu ignorieren Syntax: allgemein #pragma omp <rest of pragma> Beispiel: #pragma omp parallel for for (i = 0; i < N; i++) a[i] = b[i] + c[i]; WS 2013/14, Folie 24

25 3.1 Einführung Multi-Core-Architekturen Kanonische Form der Steuerungssyntax einer prinzipiell parallelisierbaren for-schleife kein vorzeitiges Schleifenende z.b. goto, return, break erlaubt: continue, exit, for(index start;index index index index index end; index ) index inc inc index index inc index inc index index index inc WS 2013/14, Folie 25

26 3.1 Einführung Multi-Core-Architekturen Ausführungskontext (execution context) jeder Thread hat seinen eigenen Ausführungskontext Ausführungskontext: Adressraum, der alle Variablen enthält auf die Thread möglicherweise zugreift Inhalte eines Ausführungskontextes: statische Variablen dynamisch allozierte Datenstrukturen im Heap Variablen auf dem Stack zur Laufzeit zusätzlicher Laufzeit-Stack für vom Thread aufgerufene Funktionen gemeinsame und private Variablen gemeinsame Variablen gleiche Adresse im Ausführungskontext eines jeden Thread private Variable verschiedene Adresse im Ausführungskontext eines jeden Thread Thread-übergreifend geschützt WS 2013/14, Folie 26

27 3.1 Einführung Multi-Core-Architekturen gemeinsame und private Variablen int main (int argc, char *argv[]) { int b[3]; char *cptr; int i; cptr = malloc(1); #pragma omp parallel for for (i = 0; i < 3; i++) b[i] = i; Heap Stack i b Master Thread (Thread 0) cptr i i Thread 1 WS 2013/14, Folie 27

28 3.1 Einführung Multi-Core-Architekturen Deklarieren privater Variablen neues Schleifen-Beispiel for (i = 0; i < m; i++) for (j = 0; j < n; j++) a[i][j] = MIN(a[i][j],a[i][k]+tmp); beide Schleifen können parallel ausgeführt werden. Welche wählen? Korngröße: Anzahl Schritte bis zu einer Synchronisation bzw. Kommunikation möglichst große Korngröße höherer Gewinn bei paralleler Ausführung daher Parallelisierung der äußeren Schleife reduziert Anzahl an fork/join-operationen jeder Thread braucht eigene private Kopie der Variable j WS 2013/14, Folie 28

29 3.1 Einführung Multi-Core-Architekturen ansonsten: einzelne Threads verändern unkoordiniert globale Variable j Private clause (Zusatz) Angabe mittels pragma Zusatz private ( <variable list> ) #pragma omp parallel for private(j) for (i = 0; i < m; i++) for (j = 0; j < n; j++) a[i][j] = MIN(a[i][j],a[i][k]+tmp); WS 2013/14, Folie 29

30 3.1 Einführung Multi-Core-Architekturen manchmal gewünscht: private Variable erbt zu Beginn Wert der gemeinsamen Variablen Beispiel: x[0] = complex_function(); for (i = 0; i < n; i++) { for (j = 1; j < 4; j++) x[j] = g(i, x[j-1]); answer[i] = x[1] x[3]; } Zusatz firstprivate(<variable list>) x[0] = complex_function(); #pragma omp parallel for private(j) firstprivate(x) for (i = 0; i < n; i++) { for (j = 1; j < 4; j++) x[j] = g(i, x[j-1]); answer[i] = x[1] x[3]; } WS 2013/14, Folie 30

31 3.1 Einführung Multi-Core-Architekturen Gegenstück: gewünscht: Thread, der sequentiell betrachtet, die letzte Iteration ausführt, soll Wert wieder in globale Variable zurückspeichern. Beispiel: for (i = 0; i < n; i++) { x[0] = 1.0 ; for (j = 1; j < 4; j++) x[j] = x[j-1] * (i+1); sum_of_powers[i] = x[0] + x[1] + x[2] + x[3]; } n_cubed = x[3]; Zusatz lastprivate(<variable list>) #pragma omp parallel for private(j) firstprivate(x) lastprivate(x) for (i = 0; i < n; i++) { x[0] = 1.0 ; for (j = 1; j < 4; j++) x[j] = x[j-1] * (i+1); sum_of_powers[i] = x[0] + x[1] + x[2] + x[3]; } n_cubed = x[3]; WS 2013/14, Folie 31

32 3.2 GPGPUs 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, Folie 32

33 3.2 GPGPUs 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, Folie 33

34 3.2 GPGPUs Beispiel: Direct3D 10 Pipeline WS 2013/14, Folie 34

35 3.2 GPGPUs 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, Folie 35

36 3.2 GPGPUs GPGPUs GPGPU = General Purpose Graphics Processing Unit Grafikkarten zunehmend flexibler programmierbar stetig wachsende Leistung geeignet für Streamprozessing geringes Verhältnis IO-zu-Rechenlast Datenparallelität (SIMD-Verarbeitung) Ausrichtung auf Spiele: single precision wichtiger als double precision WS 2013/14, Folie 36

37 3.2.1 GPGPU-Architektur Aufbau GPGPU WS 2013/14, Folie 37

38 3.2.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, Folie 38

39 3.2.1 GPGPU-Architektur Allgemeines Architekturschema einer Multithread-fähigen sog. Streaming Multiprozessoreinheit (SM) WS 2013/14, Folie 39

40 3.2.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, Folie 40

41 3.2.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, Folie 41

42 3.2.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/14, Folie 42

43 3.2.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 SPs 32 K Register WS 2013/14, Folie 43

44 3.2.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/14, Folie 44

45 3.2.1 GPGPU-Architektur Speicherhierarchie: Register (am schnellsten) Shared Memory/L1 Cache entweder 16 KB Cache und 48 KB Shared Memory oder 48 KB Cache und 16 KB Shared Memory 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, Folie 45

46 3.2.2 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, Folie 46

47 3.2.2 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, Folie 47

48 3.2.2 CUDA-Programmiermodell Übertragen auf Threads und kooperative Thread-Felder Dieses und folgende Bilder entnommen aus: Nvidia Programming Guide Vers , 2009 WS 2013/14, Folie 48

49 3.2.2 CUDA-Programmiermodell Übertragen auf Threads und kooperative Thread-Felder WS 2013/14, Folie 49

50 3.2.3 CUDA-Programmierung 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, Folie 50

51 3.2.3 CUDA-Programmierung 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); Kernel1<<<dimGrid,1dimBlock1>>>(,, ); WS 2013/14, Folie 51

52 3.2.3 CUDA-Programmierung Cuda Memory Management CUDA-API-Aufrufe: Allokation/Deallokation von GPGPU-RAM Transfer GPGPU-RAM -> CPU-RAM, CPU-RAM -> GPGPU-RAM cudamalloc(, ) ; cudamemcpy(,, cudamemcpydevicetohost) ; cudamemcpy(,, cudamemcpyhosttodevice) ; (CUDA)-Kernels: Transfer GPGPU-RAM <-> Shared-Memory GetElement(, ) greift auf Device-Speicher zu shared float As[BLOCK_SIZE] ; As[row] = GetElement(...,...) ; WS 2013/14, Folie 52

53 3.2.3 CUDA-Programmierung 1. CUDA - Programmbeispiel: Hello World WS 2013/14, Folie 53

54 3.2.3 CUDA-Programmierung CUDA: Hello World: WS 2013/14, Folie 54

55 3.2.3 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, Folie 55

56 3.2.3 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 = (float *) malloc(size); float* h_b = (float *) malloc(size); float* h_c = (float *) malloc(size); // Enter values in h_a and h_b... // Allocate vectors in device memory float* d_a, d_b, d_c; cudamalloc((float**)&d_a, size); cudamalloc((float**)&d_b, size); cudamalloc((float**)&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, Folie 56

57 3.2.3 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); // Output h_c... // Free device memory cudafree(d_a); cudafree(d_b); cudafree(d_c); } WS 2013/14, Folie 57

58 3.2.4 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, Folie 58

59 3.2.4 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) Warps bestehen aus zwei Half-Warps alle Threads eines Warps: quasi-parallele Ausführung Problem bei divergenten Branches: serielle Abarbeitung WS 2013/14, Folie 59

60 3.2.4 Fortgeschrittene CUDA-Programmierung 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, Folie 60

61 3.2.4 Fortgeschrittene CUDA-Programmierung 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 dieselbe Adresse: Warp Serialize (serielle Ausführung der Threads eines Warps) WS 2013/14, Folie 61

62 3.2.4 Fortgeschrittene CUDA-Programmierung 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, Folie 62

63 3.2.4 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, Folie 63

64 3.2.4 Fortgeschrittene CUDA-Programmierung Speicherzugriff Kopiert Vector src nach dst Offset verschiebt Alignment bei falschem Alignment kein Coalescing daher schlechter Durchsatz Richtigen offset finden durch Probieren, dann besserer Durchsatz WS 2013/14, Folie 64

65 3.2.4 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, Folie 65

66 3.2.4 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, Folie 66

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

68 3.2.4 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, Folie 68

69 3.2.4 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 im Cache fündig. WS 2013/14, Folie 69

70 3.2.4 Fortgeschrittene CUDA-Programmierung Matrix-Multiplikation: Shared Memory WS 2013/14, Folie 70

71 3.2.4 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, Folie 71

72 3.3 GPGPUs 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, Folie 72