Programmierung von Many-Cores. Seminar: Software Engineering für Exascale Computing

Transkript

1 Programmierung von Many-Cores Seminar: Software Engineering für Exascale Computing Patrizia Peller April 18, 2013

2 Programmierung von Many-Cores Hardware-Architekturen Anforderungen an Programmiersprachen Parallelisierung in Programmiersprachen Programmierumgebungen und Bibliotheken Plattform-spezifische Programmierumgebungen On step higher: Cross-Plattform Entwicklungsumgebungen Einordnung: welche Sprache für welche Architektur? Aussichten 2

3 3 Hardware-Architekturen 1) Six-Core AMD Opteron TM 2) Intel Xeon Phi 5110P 3) NVIDIA TESLA K20C 4) Parallella 5) Kalray 6) Anforderungen an Programmiersprachen

4 4 Gegenüberstellung AMD Opteron Intel Xeon Phi NVIDIA Parallella Kalray 5110P Tesla K20C # Kerne Kerne Leistungs- 40 bis 105 Watt 225 Watt 235 Watt 5 Watt 5 Watt aufnahme Frequenz MHz GHz MHz 800 MHz 400 MHz Rechenleistung 10 GFLOPS 1 TFLOPS 1,17 1,3 TFLOPS 25 bis 90 GFLOPS GFLOPS Architektur Direct Connect Many Integrated Cores Speicher- Verteilter L2, Verteilter L2, verwaltung gemeinsamer L3 gemeinsamer L3 Programmier- sprachen Cache N.A. Cache Cilk Plus, TBB, OpenMP, MPI, DO CONCURRENT NVIDIA CUDA Epiphany MPPA Shared Memory CUDA, OpenACC, OpenCL, DirectX, Fortran Distributed Shared Memory OpenCL, Erlang, Python, GO Distributed Memory MPPA ACCESSCORE Große Unterschiede in den technischen Spezifikationen und der Leistung Hardware-Architekturen

5 5 Six-core AMD Opteron TM Keine Unterstützung zur Thread-Verwaltung, Trotzdem gut geeignet für Programme mit Multithreading Hardware verwaltet den Arbeitsspeicher selbst Leistungsfähige, flexible Kerne, dafür weniger Hardware-Architekturen Pages/six-core-opteron.aspx

6 6 Intel Xeon Phi 5110P Many Integrated Cores Gemeinsamer Speicher ist GDDR5 Speicher => optimiert für Einsatz als GPU-Arbeitsspeicher Unterstützt massives Threading (bis 240 Threads) Arbeitet auf Vektoren -> Einschränkung bei Programmiersprachen Hardware-Architekturen

7 7 NVIDIA TESLA K20C Kepler Architektur Shared memory!!! Sehr hohe Anzahl an Kernen, dafür sehr einfach Einsatz: rechenintensive Programme mit einfachen arithmetischen Operationen Anwendungsgebiete z.b. Molekulardynamik, Quantenchemie, numerische Analytik, Physik, Wetter- und Klimavorhersage Hardware-Architekturen

8 8 Parallella und seine Architektur Epiphany distributed shared memory!!! General Purpose Prozessoren Hardware-Support für multicore data-sharing Neutral gegenüber Programmiermodellen Hardware-Architekturen epiphany_arch_reference_ pdf

9 9 Kalray MPPA 256 Cluster VLIW-Prozessor mit einfachen Kernen VLIW: Very Long Instruction Word Support für spezielle Operationen wie z.b. Bit- Shuffling oder Byte-Swapping Spezialisiert auf kryptographische Operationen Daten laufen durch Splitter, jeder Task erhält einen Teil CPU verwaltet die Threads wie bei GPUs Hardware-Architekturen

10 10 Anforderungen an Programmiersprachen 1) Energieeffizienz Künftig weniger Threads, dafür mehr Kerne => erfordert mehr Parallelität 2) Unterschied zwischen CPUs und GPUs verschwimmt 3) Portabilität von Programmen zwischen Plattformen high-level Programmiersprachen für Entwickler wünschenswert -> höhere Performanz, gute Portabilität! Trade-Off zwischen Performanz und Parallelität Hardware-Architekturen

11 11 Parallelisierung in Programmiersprachen 1) X10 - Task-basierter Lösungsansatz 2) Go: Communicating Sequential Processes 3) Scala: Parallelisierung mit dem Actor-Modell 4) Parallelisierungstechniken

12 12 Task-basiertes Programmieren Entwickler muss parallelisierbare Befehle selbst identifizieren und kennzeichnen Run-time System übernimmt eigentliches Scheduling auf vorhandener Hardware Für den Programmierer transparent Mit work-stealing-algorithmus (garantiert Ausführung in maximal doppelter Zeit als optimal) Implizit Verwendung von gemeinsamem Speicher Parallelisierung in Programmiersprachen

13 13 X10 Task-basierter Lösungsansatz Objektorientiert, compiliert zu Java-Bytecode Beruht auf dem PGAS Modell: partitioned global address space Umgebung besteht aus mehreren places (Kern/Prozessor mit eigenem Speicher) Objekte in einem place bieten nur in diesem place Lese- und Schreibrechte Activities (~Task) müssen zuerst auf diesen place verschoben werden Container wie z.b. Arrays können über mehrere places verteilt sein => erleichtert Parallelisierung Parallelisierung in Programmiersprachen Programming Many-Core Chips, Vajda András, 2011, Springer Verlag, Kapitel 8 bis 10

14 14 CSP Modell Prozesse sind statisch definiert, spezieller Mechanismus zum Kennzeichnen parallel ausführbarer sequentieller Prozesse Kommunikation zw. Prozessen nur über Nachrichten Nur wenn der Sender den Empfänger explizit nennt und umgekehrt und der Empfänger bereit ist, sonst Verzögerung Mehrere Nachrichten: eine wird ausgewählt -> nicht-deterministisch Nachrichten steuern den Kontrollfluss im Programm! Share-nothing-Prinzip: kein gemeinsamer Speicher, nur Kommunikation Ø Small-scale Anwendung in sicherheitskritischen Systemen, aber nicht geeignet für komplexere Anforderungen Parallelisierung in Programmiersprachen

15 15 Go: Communicating Sequential Processes Imperative Sprache wie Java / C++ Implementiert CSP Modell, ermöglicht aber gemeinsamen Speicher Parallelität über: Communication channels: Kommunikation zwischen Prozessen, Versand von Referenzen auf Daten und Channels Prinzip: Share memory by communicating Goroutines: werden von anderen Prozessen ausgelöst und können mit anderen Prozessen kommunizieren Parallelisierung in Programmiersprachen Programming Many-Core Chips, Vajda András

16 16 Actor-Modell Actor: Asynchrone Kommunikation mit jedem Actor möglich Führt Operationen je nach eingehender Nachricht und internem Zustand aus kann mit (beliebig vielen) Nachrichten antworten Kann neue Actors erzeugen -> dynamisch Zustellungsreihenfolge der Nachrichten nicht total Events sind dagegen total geordnet! Keine zentrale Einheit, die alleinigen Überblick über das gesamte System hat -> verteilt Parallelisierung in Programmiersprachen

17 17 Scala: Parallelisierung mit dem Actor-Modell Blend aus objektorientierter und funktioneller Sprache Compiled zu Java-Bytecode und in JVM ausgeführt für unterschiedliche Plattformen geeignet Actors werden auf Java-Thread gemapped und von der JVM gescheduled Synchrone und asynchrone Nachrichten möglich (synchron: Sender wird blockiert bis die reply des Empfängers da ist Parallelisierung in Programmiersprachen Programming Many-Core Chips; Vajda András

18 18 Parallelisierungstechniken Schleifenparallelisierung: Intel TBB: parallel_for, parallel_do, parallel_reduce OpenMP: #pragma omp parallel for SPAP: forall Compiler-Direktiven OpenMP: #pragma omp <Anweisung> OpenACC:!$acc <Anweisung>, #pragma acc <Anweisung> Spezielle Umgebungsvariablen z.b. in OpenMP Parallelisierung in Programmiersprachen Programming Many-Core Chips, Vajda András Quellen der folgenden folgenden Programmiersprachen

19 19 Parallelisierungstechniken Zusätzliche Schlüsselwörter Intel Cilk: cilk, spawn, sync X10: async, finish, atomic oder clocked Implementierung spezieller Klassen + Overriding von Methoden Scala: Klasse Actor, Methode Actor.act() Intel TBB: Klasse Task, Methode Task.execute() Microsoft TPL: Klasse Task Parallelisierung in Programmiersprachen

20 20 Programmierumgebungen und Bibliotheken Standardisierte Entwicklungsumgebungen von Betriebssystemund Hardware-Herstellern 1) Intel Cilk 2) Apple: Grand Central Dispatch 3) Microsoft Task Parallel Library Einsetzbar, wenn Hardware / OS / Applikationen bekannt hoher Parallelisierungsgrad erreichbar Weniger sinnvoll, wenn Programm auf unterschiedlichen Plattformen laufen muss

21 21 Programmierumgebungen und Bibliotheken One step higher: Cross-Plattform Entwicklungsumgebungen 1) OpenMP 2) OpenHMPP 3) OpenCL 4) SPAP Einsatzbereiche: Programme, die auf jeder CPU und/oder GPU laufen müssen Bsp: AES-Verschlüsselung, JPEG-Encoding

22 22 Intel Cilk Task-basiert: Threads werden mit Kontext initiiert und in einer Queue verwaltet, von der Prozessoren stehlen können (work-stealing) Resultat: DAG (directed acyclic graph) mit G = (V, E): V = Menge aller Knoten (hier Threads) E = Menge aller Kanten (hier Kontext des Parent-Threads) Dynamisch aufbaubar! Beispiel: cilk unsigned int fibonacci (unsigned int num) { if (num < 2) return num; else { unsigned int f1, f2; } } f1 = spawn fibonacci(num 1); f2 = spawn fibonacci(num 2); sync; return f1 + f2; Plattform-spezifische Programmierumgebungen Programming Many-Core Chips, Vajda András

23 23 Apple Grand Central Dispatch Basiert auf Compiler- Erweiterungen wie Blocks: ähnlich wie private Funktionen int(hitchhiker)(int) = ^(int n){return n*42} Ausführung dieser Blocks kann auf mehrere Queues verteilt werden Plattform-spezifische Programmierumgebungen Programming Many-Core Chips, Vajda András

24 24 Microsoft Task Parallel Library Teil des.net Frameworks seit Version 4.0 Scheduler arbeitet auf Thread-Pool, Thread local queues und mit work-stealing Besonderheit: In-lining von Tasks Task 1 Task 2 Wartet auf Task 3 Task 4 Task 5 Tasks können auch abgebrochen werden! Explizite Synchronisation erforderlich Wird vorgezogen Plattform-spezifische Programmierumgebungen Programming Many-Core Chips, Vajda András

25 25 OpenMP Task-basiert und data-parallel Parallelisierung mit Hilfe von: Synchronization primitives: Scheduling nur an bestimmten Punkten Data-Sharing Attributes: shared(x,y,z,n) ó private(i) Verschachtelte Parallelisierung: Verschachtelung von Tasks Thread-Pool-Dimensionierung und Management Runtime-System muss Scheduling der Tasks und Zuweisung zu Prozessoren übernehmen Ø Besonders geeignet für CPUs One step higher: Cross-Plattform Entwicklungsumgebungen Programming Many-Core Chips, Vajda András

26 26 OpenHMPP Hauptsächlich für GPUs Arbeitet mit Compiler-Direktiven Direktiven: beschreiben remote procedure calls auf accelerators Entwickler muss Hardware (und damit Scheduling) selbst verwalten Fokus auf Portabilität One step higher: Cross-Plattform Entwicklungsumgebungen

27 27 OpenCL Task = Kernel mit genau einem Arbeitspaket Kernel kann nicht als Host-Funktion dienen Programmausführung auf command queues Hardware zuständig für Scheduling der Queues auf OpenCL devices Devices bestehen aus mehreren Recheneinheiten Nur für GPUs, die Tasks selbst verwalten Asynchron: in-order (seriell) oder out-of-order Ausführung der Befehle Ø dynamisches task-paralleles Programmieren kaum möglich One step higher: Cross-Plattform Entwicklungsumgebungen Programming Many-Core Chips, Vajda András

28 28 SPAP Programme auf CPUs und GPUs verwendbar Definiert eigene Container wie z.b. Lists: auto pos_i = new int<>; Zwei Parallelisierungsarten: 1. Innerhalb eines Prozessors: push_back() 2. Zwischen Prozessoren: distribute() SPAP Befehle werden automatisch durch die effizienteste Implementierung des Prozessors ersetzt Scheduling: Teile von Tasks werden an Prozessoren vergeben, sobald diese frei sind Größe der Teile bestimmt durch Kapazität des Prozessors oder Entwickler One step higher: Cross-Plattform Entwicklungsumgebungen SPAP: A Programming Language for Heterogenous Many- Core Systems.Qiming Hou, Kun Zhou, Baining Guo. Graphical and Parallel Systems Lab, Zhejiang University. 2010

29 Einordnung: Welche Sprache für welche Architektur? 29

30 Automatisierung Aussichten Immer noch direkte Anweisungen erforderlich, wo Parallelisierung in einem Programm möglich ist Higher level High-level Programmiersprachen mit Parallelisierungsmechanismen versehen Neue Technologien NVIDIA Volta (GPU mit bis zu 1TB/s Bandbreite, vermutlich 2016): neue Technologie mit Stacked DRAM Devise: weg von Threads hin zu Cores 30