Intels Tick-Tock-Prinzip

Transkript

1 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 2010/ Folie 42

2 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 2010/ Folie 43

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

4 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 2010/ Folie 45

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

6 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Energiesparzustände der Cores Vorher nur Spannung und Frequenz für alle Kerne global regelbar Ineffizient, da Last auf Kerne zumeist ungleich verteilt WS 2010/ Folie 47

7 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 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 2010/ Folie 48

8 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 Da verschiedene Threads meistens keine Datenabhängigkeit aufweisen, können die Rechenwerke besser ausgelastet werden, was zu größerem Gesamtdurchsatz führt. WS 2010/ Folie 49

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

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

11 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Speicher-Controller (Stand ) 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 2010/ Folie 52

12 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 2010/ Folie 53

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

14 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 2010/ Folie 55

15 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 2010/ Folie 56

16 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 2010/ Folie 57

17 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 2010/ Folie 58

18 2.3 Beispiele für Multikern-Architekturen Intel-Nehalem-Architektur Nehalem-Modelle im Vergleich WS 2010/ Folie 59

19 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 2010/ Folie 60

20 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 2010/ Folie 61

21 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 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 Jede Lade-/Speichereinheit mit jeweils zwei Lade/Speicheroperationen / Takt ergibt 72 Mikrooperationen die umgeordnet gleichzeitig ausführbar sind WS 2010/ Folie 62

22 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 2010/ Folie 63

23 2.3 Beispiele für Multikern-Architekturen AMD-Istanbul / Magny-Cours Opteron-Architekturen L2 Cache ist sog. Victim Cache für Instruktionen und Daten aus dem L1 Cache 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 vorhandenen L1 Eintrag in L2 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 WS 2010/ Folie 64

24 2.3 Beispiele für Multikern-Architekturen AMD-Istanbul-Architektur Cache kokärenz in Multiprozessorsystemen besonderes Problem HT-Assist Directory-(Verzeichnis)-Protokoll Analog der Forward-Erweiterung 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 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 2010/ Folie 65

25 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. 1. 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 WS 2010/ Folie 66

26 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 that 4-Way memory bandwidth improves 60%: 41.5GB/s with HT Assist versus 25.5GB/s without HT Assist. WS 2010/ Folie 67

27 2.3 Beispiele für Multikern-Architekturen Heterogene-Multikern-Architekturen Cell BE Viele Rechenaufgaben können auf verschiedene CPUs und/oder Maschinen aufgeteilt und verteilt werden, um die Leistung zu steigern Herkömmliche CPUs und Techniken sind nicht ausreichend: CPUs in einer SMP (symmetrischer Multiprozessor) Umgebung u.u. sehr teuer Zu große Platzverschwendung durch große Caches => kleiner Core, weniger GFLOPs/GOPs Zu viel Zeit wird beim Warten auf Daten aus dem Speicher verschwendet Cell verfolgt heterogenen Ansatz Verschiedene Prozessorarchitekturen auf einem Chip für Spezialaufgaben WS 2010/ Folie 68

28 2.3 Beispiele für Multikern-Architekturen Heterogene-Multikern-Architekturen Cell BE Cell ist ein Prozessor Design ein Programmierparadigma Lt. eigener Angabe: revolutionäres neues Prozessor-Design: 1 Prozessoreinheit und bis zu 8 unabhängige SIMD- (Single Instruction Multiple Data)- bzw. Vektor-Prozessoren Nominell 150 GFLOPS möglich Keine On-Chip Caches auf den 8 SIMD-Prozessoren Verteilung von kleinen unabhängigen Tasks auf verschiedene SIMD-Prozessoren Ermöglicht massives paralleles Rechnen Im Prinzip: gesamter Vektorrechner auf einem Chip WS 2010/ Folie 69

29 2.3 Beispiele für Multikern-Architekturen Heterogene-Multikern-Architekturen Cell BE Geschichte Entwicklung Cell Joint Venture von Sony, Toshiba und IBM (STI) Patent ausgestellt an Masakazu Suzuoki u. Takeshi Yamazaki (Sony) am an STI am Wird CPU für PlayStation3 IBM plante Produktion im ersten Halbjahr 2005 Erster Server und Workstations Ende 2005 von IBM Einsatz in HDTV Systeme von Sony und Toshiba seit 2006 Implementiert in 90 Nanometer Technologie seit 2007 in 65 nm Prototyp mit 234 Millionen Transistoren auf 221 mm² Vorgestellt 2005 auf der ISSCC (Int. Solid State Circuits Conference) WS 2010/ Folie 70

30 2.4.1 Heterogene-Multikern-Architekturen Cell BE Chip und Layout WS 2010/ Folie 71

31 2.4.1 Heterogene-Multikern-Architekturen Cell BE Aufbau Cell BE Architektur (grob) Power Processor Element (PPE) POWER Architecture Based L1 Cache L2 Cache DRAM SPE 1 SPE 2 SPE 3 SPE 4 EIB SPE 5 SPE 6 SPE 7 SPE 8 MIC BIC WS 2010/ Folie 72

32 2.4.1 Heterogene-Multikern-Architekturen Cell BE Aufbau Cell BE Architektur (detaillierter) WS 2010/ Folie 73

33 2.4.1 Heterogene-Multikern-Architekturen Cell BE Aufbau Cell BE Architektur 1 Power PC Processor Element (PPE) Kann 2 Threads gleichzeitig bearbeiten Beinhaltet 32 KB L1 Cache Enthält spezielle Vektoreinheit VMX/AltiVec 8 Vektorprozessoren: Synergistic Processor Elements (SPEs) Element Interface Bus (EIB) Besteht aus 4 x 16 Byte großen Datenringen Kann 96 Bytes/Zyklus übertragen WS 2010/ Folie 74

34 2.4.1 Heterogene-Multikern-Architekturen Cell BE Dual Channel Memory Interface Controller (MIC) 12.8 GByte/s pro Kanal Gesamte Bandbreite 25.6 GBytes/s Ursprünglich nur anschließbar an Rambus Standard Seit PowerX8Cell auch DDR2-RAM möglich Dual Channel Bus Interface Controller (BIC) Insgesamt Bandbreite 76.8 GBytes/s 512 KB L2 Cache WS 2010/ Folie 75

35 2.4.1 Heterogene-Multikern-Architekturen Cell BE PPE Power Processor Element WS 2010/ Folie 76

36 2.4.1 Heterogene-Multikern-Architekturen Cell BE SPE - Vektor (oder SIMD) Prozessor WS 2010/ Folie 77

37 2.4.1 Heterogene-Multikern-Architekturen Cell BE Unabhängige Verarbeitung SPEs sind keine Koprozessoren sondern unabhängige Einheiten SPEs führen eigenständige Programme aus Programme werden vom PPE in lokale Speicher der SPEs geladen Jede SPE Ausführungseinheit SPU bzw. SXU (SPE Execution Unit) operiert auf 128 Bitvektoren die aus vier 32 Bitelementen aufgebaut sein können Direkter Speicherzugriff über DMA Zentrale Kommunikationseinheit kann gleichzeitig zur SPU-Einheit laufen WS 2010/ Folie 78

38 2.4.1 Heterogene-Multikern-Architekturen Cell BE SPE - Vektor (oder SIMD) Prozessor 256 KB lokaler SRAM 128 x 128 Bit Register 1 DMA Kontroller 1 Leitwerk 4 Fließkomma-Einheiten Gesamtleistung: 32 GFLOPS 4 Ganzzahlrechenwerke Gesamtleistung 32 GOPS WS 2010/ Folie 79

39 2.4.1 Heterogene-Multikern-Architekturen Cell BE Programmierbeispiel: Hello - Cell Hauptprogramm auf PPE #include <stdlib.h> #include <stdio.h> #include <errno.h> #include <libspe2.h> #include <pthread.h> extern spe_program_handle_t simple_spu; #define MAX_SPU_THREADS 16 void *ppu_pthread_function(void *arg){ spe_context_ptr_t ctx; unsigned int entry = SPE_DEFAULT_ENTRY; ctx = *((spe_context_ptr_t *)arg); spe_context_run(ctx, &entry, 0, NULL, NULL, NULL) ; pthread_exit(null); } WS 2010/ Folie 80

40 2.4.1 Heterogene-Multikern-Architekturen Cell BE int main() { int i,spu_threads; spe_context_ptr_t ctxs[max_spu_threads]; pthread_t threads[max_spu_threads]; /* Determine the number of SPE threads to create */ spu_threads = spe_cpu_info_get(spe_count_usable_spes, -1); if (spu_threads > MAX_SPU_THREADS) spu_threads = MAX_SPU_THREADS; /* Create several SPE-threads to execute simple_spu */ for(i=0; i<spu_threads; i++) { } /* Create context */ ctxs[i] = spe_context_create (0, NULL); /* Load program into context */ spe_program_load (ctxs[i],&simple_spu); /* Create thread for each SPE context */ pthread_create (&threads[i],null,&ppu_pthread_function,&ctxs[i]) ; /* Wait for SPU-thread to complete execution. */ for (i=0; i<spu_threads; i++) pthread_join (threads[i], NULL) ; } return (0); WS 2010/ Folie 81

41 2.4.1 Heterogene-Multikern-Architekturen Cell BE Programm auf SPE simple_spu.c #include <stdio.h> int main(unsigned long long id) { /* The first parameter of an spu program will always be the spe_id of the spe thread that issued it. */ printf("hello Cell (0x%llx)\n", id); return 0; } WS 2010/ Folie 82

42 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System 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 2010/ Folie 83

43 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System 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 2010/ Folie 84

44 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System 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 2010/ Folie 85

45 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System 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 2010/ Folie 86

46 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System 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 2010/ Folie 87

47 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Logische Graphik Pipeline Shader Programm, das Schattierungen vornimmt Auf Knotenpunkte (Vertex), auf Geometrische Primitive (Vertexes, die Geraden, Dreiecke, ) zusammengefasst sind) und einzelnen Bildpunkten Blaue Einheiten programmierbar, weiße fest verdrahtet Texturen beschreiben Oberflächeneigenschaften von Punkten von interpolierte Fließkomma-Koordinaten häufig in 1D, 2D- oder 3D-Feldern abgelegt WS 2010/ Folie 88

48 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Beispiel Microsofts Direct3D 10 Pipeline Logische Pipeline abgebildet auf physikalischen Prozessor Blaue Einheiten nun durch Programm (Threads) realisierbar WS 2010/ Folie 89

49 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Allgemeiner Aufbau GPGPU WS 2010/ Folie 90

50 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Aufbau realer GPGPU- NVIDIA GeForce Streaming-Prozessoren (SP) organisiert in 14 Streaming- Multiprozessoren (SM) WS 2010/ Folie 91

51 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System 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 2010/ Folie 92

52 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Paralleles Programmiermodell Datenparallelität Problemraum zerlegen in kleinere Problemräume (geometrische Dekomposition) Diese parallel lösen Threadparallelität Jeder Ergebnisblock wird mit einem Feld fein-granularer Threads gelöst Jeder Thread löst ein oder einige wenige Ergebniselemente Zwei-Ebenen Parallelität Grob-granulare Thread-Blöcke mit SM Fein-granulare Threads mit SP WS 2010/ Folie 93

53 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Beispiel für Rendering-Prozess Void reflection( float2 texcoord : TEXCOORD0, float3 reflectdir : TEXCOORD1, out float4 color : COLOR, uniform float shiny, uniform sampler2d surfacemap, uniform samplercube envmap) { // Fetch the surface color from a texture float4 surfacecolor = tex2d(surfacemap, texcoord); } // Fetch reflected color by sampling a cube map float4 reflectedcolor = tex2d(envmap, reflectdir); // Output is weighted average of the two colors color = lerp(surfacecolor, reflectedcolor, shiny); GPU-rendered image. To give the skin visual depth and translucency, the pixel shader program models three separate skin layers, each with unique subsurface scattering behavior. It executes 1400 instructions to render the red, green, blue, and alpha color components of each skin pixel fragment. Copyright 2009 Elsevier, Inc. All rights reserved. WS 2010/ Folie 94

54 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Umsetzung mit CUDA (Compute Unified Device Architecture) CUDA liefert drei Schlüsselabstraktionen Hierarchie von Gruppen an Threads Gemeinsamer Speicher Barrieren-Synchronisation Art Virtualisierung Programmierer zerlegt Problem zunächst in gröbere Subprobleme werden parallel gelöst Anschließend in feinere Stücke (Gitterpunkte) werden wieder parallel gelöst Skaliert transparent für Programmierer beliebige Zahl von Prozessoren verfügbar CUDA-Laufzeitsystem hat Aufgabe das Programm auf Hardware abzubilden und zu planen WS 2010/ Folie 95

55 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Folgende Mechanismen, Hierarchien zu bilden Kernel Ein Programm oder eine Funktion für einen Thread Kann von vielen Threads ausgeführt werden Thread Block Eine Menge von nebenläufig ausgeführten Threads, die das gleiche Thread-Programm ausführen und zusammenarbeiten, um ein Problem zu lösen Grid Eine Menge von Threadblöcken, die den gleichen Kernel ausführen WS 2010/ Folie 96

56 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Beispiel für Umsetzung mit CUDA Realisiert in BLAS (Basic Linear Algebra Subprograms)-Bibliothek WS 2010/ Folie 97

57 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Speicherhierarchie Lokaler Speicher Privater Speicher pro Thread Gemeinsamer Speicher Speicher pro Thread-Block Alle Threads eines Blocks greifen auf gemeinsamer Speicher zu Globaler Speicher Speicher pro Applikation Gemeinsamer Speicher für alle Threads über alle Blöcke WS 2010/ Folie 98

58 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Graphische Darstellung Verschachtelte Thread-Körnigkeit und Speicherzugehörigkeit WS 2010/ Folie 99

59 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Modell ähnlich dem SPMD (Single Program Multiple Data) Jeder Kernel-Aufruf kann dynamisch neue Gittergrößen erzeugen S. Beispiel rechts WS 2010/ Folie 100

60 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Wo werden Thread-Blöcke ausgeführt? Auf SM gemäß SIMT (Single Instruction Multiple Thread) verallgemeinerte Architektur gezeigt WS 2010/ Folie 101

61 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Ablaufplanung? SIMT multithreaded warp scheduling Single Imstruction Multiple Thread Eine Instruktion wird auf mehrere parallel ausgeführt und unabhängige Threads verteilt Warp Mehrere Threads werden zu einem sog. Warp zusammengefasst Z.B. 32 Threads in Warp ausgeführt auf dem 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 2010/ Folie 102

62 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System 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 eigen Datenbereiche SP Register werden unter Threads gleichmäßig aufgeteilt WS 2010/ Folie 103

63 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Zusammenfassung Programmiermodell sehr viele Threads kurzlebige Threads da geringer Overhead viele Threads um Latenz vom Speicher zu verdecken Threads werden in Blöcken gruppiert Blöcke werden auf Multi-Prozessoren verteilt Standards: CUDA (NVIDIA, Marktführer) OpenCL (offener Standard, entsprechend zu OpenGL) FireStream (AMD) DirectCompute (Microsoft) WS 2010/ Folie 104

64 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Konkretes Beispiel: CUDA Programmierung in C Function-Offloading: einzelne Funktionen laufen auf GPGPU (Kernels) 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 2010/ Folie 105

65 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Cuda Memory Management CUDA-API-Aufrufe: Allokation/Deallokation von GPGPU-RAM Transfer CPU-RAM <-> GPGPU-RAM Kernels: Transfer GPGPU-RAM <-> Shared-Memory Spezielle Speicherbereiche: Konstanten Texturen (verschiedene Adressierungen) WS 2010/ Folie 106

66 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System CUDA: Hello World WS 2010/ Folie 107

67 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System CUDA: Hello World: WS 2010/ Folie 108

68 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System CUDA: Vektor-Addition res = a + x b WS 2010/ Folie 109

69 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System CUDA: Vektor-Addition WS 2010/ Folie 110

70 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Hardware-Details: NVIDIA vs. ATI WS 2010/ Folie 111

71 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Hardware-Details: AMD Radeon HD 5970 SIMD-Engine (links) beinhaltet 16 VLIW-Units (rechts) WS 2010/ Folie 112

72 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Hardware-Details: AMD Radeon HD 5970 Multiprozessor AMD Nomenklatur: SIMD-Engine beinhaltet 16 Thread-Prozessoren 5-fach VLIW-Design 4 normale Pipelines Single-Precision-Float- und Integer-Rechenwerk Eine erweiterte Pipeline Double-Precision und spezielle Funktionen. Register WS 2010/ Folie 113

73 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System Hardware-Details: AMD Radeon HD 6970 Multiprozessor AMD Nomenklatur: SIMD-Engine beinhaltet 16 Thread-Prozessoren 4-fach VLIW-Design 4 normale Pipelines Double-Precision-Leistung ¼ der Single-Precision-Leistung Register WS 2010/ Folie 114

74 2.4.2 Heterogene-Multikern-Architekturen GPGPUs Hardware-Details: AMD Radeon HD fach VLIW-Design (Gegensatz zum alten 5-fach Design) WS 2010/ Folie 115

75 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System 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 32k Register WS 2010/ Folie 116

76 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System NVIDIA Fermi WS 2010/ Folie 117

77 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System 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 2010/ Folie 118

78 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System 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 2010/ Folie 119

79 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System 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) WS 2010/ Folie 120

80 2.4.2 GPGPU & CPU Heterogenes Multiprozessor-System 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 2010/ Folie 121