Programmierung von Many-Cores

Transkript

1 Patrizia Peller Betreuer: Armin Größlinger, Prof. Dr. Christian Lengauer Programmierung von Many-Cores Seminar: Software Engineering für Exascale Computing Abstract In dieser Arbeit werden Programmiersprachen und Entwicklungsumgebungen erklärt und gegenüber gestellt, die sich zur Entwicklung von hoch skalierbaren Programmen eignen. Häufig verwendete Techniken wie Schleifenparallelisierung oder der Einsatz erweiterter Compiler-Befehlssätze tragen ebenso dazu bei, dass Programme in hohem Maße parallelisiert werden können, wie spezielle Programmiermodelle. Auf Grund der großen Unterschiede zwischen den Architekturen gängiger Hauptprozessoren und Graphikkarten, ist es schwierig, effiziente Programmiersprachen zu entwickeln, die sich für den Einsatz auf allen Architekturen eignen. Zumal die Grenzen zwischen Hauptspeicher und Graphikkarten immer mehr verschwinden. Deswegen wird hier eine Übersicht über gängige Architekturen und Programmiersprachen geben und ein Versuch unternommen, die Sprachen und Umgebungen so einzuordnen, dass für jede Architektur eine passende Lösung gefunden werden kann. 1 Einleitung Hardware-Hersteller wie Intel, AMD oder NVIDIA entwickeln unabhängig von einander völlig unterschiedliche Architekturen für Prozessoren und Graphikkarten, die ebenso unterschiedliche Anforderungen an moderne Programmiersprachen stellen. Es werden immer mehr Kerne verbaut, sodass Programme immer skalierbarer werden und die Programmiersprachen und umgebungen dies unterstützen müssen. Die zunehmend fließenderen Grenzen zwischen den Recheneinheiten sowie Spezialentwicklungen verkomplizieren die Entwicklung von Programmiersprachen, die diese massive Parallelisierung erlauben, zusätzlich. Auf eine Architektur, eine Entwicklungsschiene von Architekturen oder ein Betriebssystem optimierte Sprachen und Umgebungen reichen oft nicht aus, um den Anforderungen der Entwickler und Benutzer gerecht zu werden. Da Programme auf immer mehr Plattformen laufen sollen, gewinnt Portabilität zunehmend an Bedeutung, was sich wiederum auf die Programmiersprachen und Entwicklungsumgebungen auswirkt. Aus diesen unterschiedlichen Anforderungen ist bereits eine Vielzahl von Lösungen entstanden, sodass es schwer ist, die Richtige aus diesem Pool auszuwählen. Im Folgenden werden deshalb einige gängige und spezielle Hardware-Architekturen, Programmiersprachen und Entwicklungsumgebungen vorgestellt und miteinander verglichen, sodass ein Versuch unternommen werden kann, eine geeignete Einordnung vorzunehmen. Wichtige Parallelisierungstechniken und Programmiermodelle werden ebenfalls erläutert, um diese Einordnung und die Funktionalität der einzelnen Lösungen zu verdeutlichen. Programmierung von Many-Cores 1

2 2 Problemstellung Für fast jeden Anwendungsbereich gibt es mittlerweile optimierte Hardware, jeder Hersteller entwickelt seine eigene Architektur und entsprechend groß ist die Auswahl. Die Unterschiede der Lösungen sind ebenso vielfältig wie die Anzahl der Entwicklungen. Zusätzlich können GPUs 1 nicht mehr nur für aufwändige Darstellungen, Bild- und Videoverarbeitung genutzt werden, sondern können vielseitiger eingesetzt werden. Zunächst werden nun CPUs 2 von AMD, Intel, Parallella und Kalray sowie eine GPU von NVIDIA miteinander verglichen, um im Anschluss die sich daraus ergebenden Anforderungen an Programmiersprachen diskutieren zu können. 2.1 Hardware Die im Folgenden beschriebenen Komponenten sind jeweils nur Stellvertreter für ganze Serien dieser Hersteller, welche das obere Ende ihrer Entwicklungsschiene markieren. In ihrer Ausstattung und den technischen Spezifikationen gibt es deutliche Unterschiede, die in Abbildung 1 gegenübergestellt sind. Hervorstechend sind dabei die Spannweite in der Anzahl der Kerne sowie der Rechenleistung. Aber auch im Energieverbrauch ist eine hohe Disparität erkennbar. Abbildung 1Gegenüberstellung der technischen Spezifikationen des Six-core AMD Opteron TM, Intel Xeon Phi 5110P, NVIDIA Tesla K20C, Parallella und Kalray Six-core AMD Opteron TM Der AMD Opteron TM in 6-Kern-Austattung wurde speziell für Server entwickelt und umfasst entsprechend dem Datenblatt auf [2] je nach Ausstattung 6 bis 12 Kerne in 45 nm Prozessortechnologie. Bei normaler Auslastung hat er eine Leistungsaufnahme von 40 bis 105 Watt bei einer Frequenz zwischen und MHz. Damit ist der Opteron TM in der Lage, bis zu 10 GigaFLOPS 3 zu bewältigen. Jeder Kern hat einen eigenen integrierten Level-2- Cache (RAM), verwaltet ihren Arbeitsspeicher also selbst, und kann durch die Direct Connect Architektur 1 GPUs: Graphics Processing Units 2 CPUs: Central Processing Units 3 FLOPS: Floating Point Operations per Second (hier in double-precision) Abbildung 2 Skizze der Direct Connect Architektur des AMD Opteron TM Programmierung von Many-Cores 2

3 einfach mit weiteren Kernen kombiniert werden. Dadurch wird eine sehr hohe Skalierbarkeit erreicht, sodass auf einem Server mit Six-core AMD Opteron TM CPU mehr virtuelle Maschinen laufen können als bei vergleichbarer Intel CPU, z.b. Six-core Intel Xeon (Dunnington), wie in AMD s Server und Workstation Architekturvergleich[1] erläutert wird. Der Opteron TM bietet zwar laut dem Vergleich keine Unterstützung zur Thread-Verwaltung, eignet sich aber dennoch gut für Multithreading. Wie der Dokumentation auf AMD s Homepage[2] zu entnehmen ist, greifen die Kerne über einen globalen Memory Controller auf den gemeinsamen Level-3-Cache zu Intel Xeon Phi 5110P Der Intel Xeon Phi 5110P besteht entsprechend dem Datenblatt [11] aus 60 Kernen in 45nm Prozessor- Technologie und erreicht eine Rechenleistung von 1 TeraFLOPS bei einer Leistungsaufnahme von 225 Watt unter Normallast mit einer Frequenz von GHz. Damit ist der Intel Xeon Phi 5110P in der Lage, bis zu 240 Threads zu verwalten. Jeder einzelne Kern kann in einer in-order Pipeline bis zu 4 Threads unterstützen. Laut Architekturbeschreibung von Intel kommunizieren die Kerne über einen bidirektionalen Ringbus mit einander und mit dem L3- Arbeitsspeicher. Obwohl der Xeon Phi eine CPU ist, wird ein GDDR5 4 Hauptspeicher im L3, welcher für Graphikkarten ausgelegt ist, eingesetzt. Jeder Kern hat zusätzlich einen eigenen L2-Cache. Abbildung 3 Skizze der Many Integrated Cores (MIC) Architektur des Intel Xeon Phi 5110P Dadurch dass der Xeon Phi mit Vektoren rechnet, sind Entwickler in der Wahl ihrer Programmiersprache eingeschränkt. Es werden beispielsweise Intel Cilk Plus, Intel Thread Building Blocks, Open MP, MPI und DO CONCURRENT unterstützt NVIDIA TESLA K20C Wie in der Produktbeschreibung von NVIDIA [8] beschrieben, besteht die NVIDIA TESLA K20C general purpose GPU aus Recheneinheiten und schafft damit eine Rechenleistung von 1,17 bis 1,34 TeraFLOPS bei einer Leistungsaufnahme von 235 Watt. Die einzelnen Kerne sind dabei deutlich einfacher als bei CPUs, weshalb sich die TESLA K20C sehr gut für rechenintensive Programme mit einfachen arithmetischen Operationen eignet. Diese können besonders gut unterstützt werden, da bis zu Rechenanweisungen gleichzeitig ausgeführt werden können, so viele wie es Kerne gibt. Die NVIDIA CUDA TM Architektur bietet dafür laut NVIDIAs Internetseite [9] schnellen Zugriff auf die einzelnen Kerne, da diese in 15 SMX 5 -Einheiten mit je 192 Kernen in einem 2D-Array angeordnet sind. Diese SMX- Einheiten greifen auf einen gemeinsamen RAM zu, wie in einem Whitepaper von NVIDIA [10] dargestellt ist, sodass die GK110 Prozessorhardware Threads selbst erstellen und verwalten und die Art der Parallelisierung dynamisch anpassen kann. 4 GDDR: Graphics Double Data Rate, Zusatzbezeichnung für DDR-Arbeitsspeicher 5 SMX: Streaming Multiprocessor Programmierung von Many-Cores 3

4 Die CUDA TM Programmiersprache und -plattform können auch in Kombination mit DirectX, Fortran oder high-level Sprachen wie OpenACC oder OpenCL angewendet werden und liefern ein optimiertes Ergebnis. Durch die Architektur und die angepasste Entwicklungs-umgebung eignet sich die NVIDIA TESLA K20C entsprechenden Aufstellungen von NVIDIA [8] zufolge, besonders für den Einsatz in der Bioinformatik, der Physik, der Quantenchemie, den Material-wissenschaften und numerischen Analytik. Aber auch Berechnungen zum Beispiel zur Molekulardynamik oder zur Klimaund Wettervorhersage oder ähnlich mathematisch aufwändigen Problemen können mit der NVIDIA TESLA K20C effizient gelöst werden. Abbildung 4Kepler-Architektur des GK110 Prozessors einer NVIDIA TESLA K20C GPU Parallella Mit seinen 16 bis 64 Kernen, die bei einer Rechenleistung von bis zu 90 TeraFLOPS ca. 5 Watt Leistungsaufnahme unter Normallast aufweisen, ist die Parallella-CPU eine der stromsparendsten CPUs. Die einzelnen Kerne sind laut [4] in der Epiphany-Prozessorarchitektur in einem 2D-Array von Netzwerkknoten angeordnet, von denen jeder eine RISC CPU, eigenen Arbeitsspeicher, eine DMA-Engine und ein Netzwerk- Interface enthält, wie man Abbildung 5 entnehmen kann. Jeder Knoten ist über ein On-Chip und ein Off- Chip Write Netzwerk sowie einem Read Request Netzwerk mit einem emesh-router verbunden, die untereinander in einem Gitternetz verlinkt sind. Dadurch ist es möglich, dass jeder Kern nicht nur auf seinen eigenen RAM zugreifen kann, sondern auch auf die Caches der anderen Netzwerkknoten, sodass der Cache zwar verteilt ist, aber eine logische Einheit bildet und somit ein distributed shared memory entsteht. Insgesamt fällt Parallella in die Kategorie der general purpose Prozessoren und unterstützt multi-core datasharing. Durch seine spezielle Architektur und das Network-on-Chip ist diese CPU neutral gegenüber Abbildung 5 Die Architektur Epiphany der Parallella CPU verbindet jeweils eine RISC-CPU, einen L2-Cache, eine DMA Engine und ein Netzwerk Interface zu einem Netzwerkknoten. (Darstellung in Anlehnung an die Visualisierung auf der Homepage von Parallella [5]) Programmierung von Many-Cores 4

5 Programmiermodellen, sowohl task-basiertes Programmieren als auch das CSP oder Actor-Modell können hierauf realisiert werden Kalray Die Kalray-CPU ist in Ausführungen mit 256 bis 1024 Kernen erhältlich und kann je nach Ausstattung 230 bis 960 GFLOPS bei einer Leistungsaufnahme von lediglich 5 Watt bei mittlerer Auslastung erreichen. Die hier verbauten VLIW-Kerne 6 sind in Paaren von 16 zusammen mit jeweils einem Systemkern und integriertem Speicher in Clustern angeordnet. Diese Cluster wiederum werden als Multipurpose Prozessor-Array über ein Highspeed Network-on- Chip verwaltet. Laut der Website des Herstellers [13] eignet sich die MPPA Architektur der Kalray CPU besonders gut für spezielle Operationen wie z.b. Bit-Shuffling oder Byte-Swapping und wurde für die Anwendung im kryptographischen Bereich optimiert. Wie dort beschrieben wird, werden Daten, um Parallelisierung zu unterstützen, aufgeteilt und können dann vom Compiler voll-automatisch auf die Cluster verteilt werden. Die durch das Splitting entstehenden Threads werden von Kalray ähnlich wie GPUs verwaltet. Abbildung 6 Die MPPA Architektur bündelt die Kerne des Kalray zu Clustern der Größe 16 zusammen mit je einem Systemkern und integriertem Speicher pro Cluster. MPPA ACCESSCORE, die von der Firma Kalray eigens entwickelte Programmierumgebung, basiert auf C und C++ und bringt für die Umsetzung dieses Splittings sowie des gesamten Workflows extra einen dafür spezialisierten Compiler mit. 2.2 Anforderungen und Herausforderungen an Programmiersprachen Die Unterschiede und Vielfalt der CPUs und GPUs führt dazu, dass sich Programmiersprachen anpassen müssen. Jedoch kommen nicht nur von Hardware-Seite neue Ansprüche, sondern auch äußere Einflüsse wie die zunehmende Ressourcenknappheit von Energie zeigen ihre Wirkung Energieeffizienz Dadurch dass Energie immer knapper wird, weil fossile Energieträger wie Kohle oder Erdöl ständig knapper werden, Atomkraftwerke mit der Zeit abgeschaltet werden und die Technologien zur Erzeugung regenerativer Energien aber noch nicht ausgereift genug sind, dass sie den steigenden Bedarf ebenso gut decken könnten, wie Atomkraft dies vermag, ist es von Nöten, dass auch Rechner effizienter arbeiten. Durch Threading von Programmen kann dies bereits gesteigert werden, wie im Whitepaper Physical Cores 6 VLIW = Very Long Instruction Word Programmierung von Many-Cores 5

6 vs. Enhanced Threading Software: Performance Evaluation Whitepaper [3] dargestellt wird, bietet Scheduling von Tasks auf mehrere Kerne aber ein höheres Potential zur Performanzsteigerung als Theading dies vermag. Höhere Performanz bedeutet aber auch weniger Energieverbrauch, weshalb die Hersteller aktueller Hardwarearchitekturen immer mehr Kerne verbauen und die Tendenz deshalb, wie auch von Vajda in Programming Many-Core Chips [16] dargestellt, weg vom Multithreading zu mehr Kernen geht. Dieser Wandelt bedeutet aber, dass Programme verstärkt parallelisierbar sein müssen und damit auch die verwendeten Programmiersprachen Unterschied zwischen CPUs und GPUs verschwimmt Ein weiteres Problem für moderne Programmiersprachen ist, dass der Unterschied zwischen Central Processing Units und Graphikkarten immer undeutlicher wird. Beispielsweise werden die eingesetzten Recheneinheiten für GPUs zunehmend allgemeiner einsetzbar, während die CPUs mit immer mehr Kernen ausgestattet werden und damit ähnlich leistungsfähig wie GPUs werden. Somit ist es nötig, dass Programmiersprachen mehr und mehr von der Hardware abstrahieren, aber dennoch effiziente Parallelisierung ermöglichen und nicht mehr explizit für eine spezielle Komponente eingesetzt werden sollten Portabilität von Programmen zwischen Plattformen Programme sollen aber oft nicht nur auf einer einzigen CPU oder GPU ausführbar sein können, sondern auf unterschiedlichsten Plattformen und Architekturen. High-level Programmier-sprachen, welche von der Hardware- und Betriebssystemebene abstrahieren, werden oft gewünscht, um von diesem Level unabhängig sein zu können. Aber nicht nur diese Unabhängigkeit ist Ziel der angestrebten Portabilität. Highlevel Sprachen sind auch für die Entwickler wünschenswert, da diese sich keine Gedanken über die verwendeten Komponenten und Betriebssysteme oder über das Scheduling der Tasks auf die Hardware machen müssen, sodass sie effizienter arbeiten können. Auf Grund der Abstraktion ist aber laut Vajda [16] bisher weniger Parallelität möglich, als bei Hardware näheren Lösungen. 3 Parallelisierungstechniken in Programmiersprachen Um Parallelisierung in Programmiersprachen zu bringen wurden mehrere Programmiermodelle entwickelt, die die Voraussetzungen mehr oder weniger gut erfüllen. Sie unterscheiden sich wiederum in Aspekten wie der Kommunikation oder den Synchronisationsmechanismen. Im Folgenden werden drei der wichtigsten Modell vorgestellt und an Hand von Sprachen, welche das jeweilige Modell aufgegriffen haben, erläutert. 3.1 Communicating Sequential Processes Das Modell des Communicating Sequential Processes kurz CSP zeichnet sich, wie von Vajda in [16] beschrieben, dadurch aus, dass die einzelnen Prozesse statisch definiert sein müssen und es dadurch nötig wird, dass parallelisierbare sequentielle Prozesse mit Hilfe eines speziellen Mechanismus gekennzeichnet werden. Der Kontrollfluss innerhalb eines Programms wird hier ausschließlich über Nachrichten gesteuert, welche das alleinige Mittel zur Kommunikation darstellen. Laut Vajda [16] kann eine Nachricht nur dann verschickt werden, wenn der Sender-Prozess den Empfänger explizit benennt und umgekehrt. Prozess A muss also mitteilen, dass er eine Nachricht an Prozess B senden möchte, und Prozess B muss erklären, dass er Nachrichten von A erhalten möchte. Es ist dafür also unbedingt erforderlich, dass die Prozesse sich gegenseitig kennen. Eine Nachricht kann selbst dann nur gesendet werden, wenn der Empfänger bereit ist, sie zu empfangen. Sind mehrere Nachrichten Programmierung von Many-Cores 6

7 eingegangen wählt der Empfänger zufällig eine aus, die er als nächstes bearbeitet, wodurch eine Quelle für Nichtdeterminismus [16] entsteht. Speicher wird dabei im CSP-Modell in keiner Weise geteilt, es kann lediglich kommuniziert werden, um Daten auszutauschen Go Die eigens von Google entwickelte Programmiersprache Go löst diesen Engpass, indem es im Gegensatz zum reinen CSP-Modell gemeinsamen Speicher zulässt. Die imperative Programmiersprache weist zwar, wie in dem Abschnitt über Go in [16] beschrieben, auch Merkmale des Task-basierten Programmierens oder des Actor Modells auf, wird aber dennoch wegen der Wichtigkeit der Kommunikation in die Kategorie des Communicating Sequential Processes eingeordnet. Parallelität wird hier in erster Linie über zwei Mechanismen erreicht. Goroutines stellen Prozesse dar, die auch von anderen Prozessen erzeugt werden und Nachrichten mit anderen Prozessen austauschen können, sofern sie diese kennen. Damit ist der Prozessbaum bei Go dynamisch aufbaubar, während er im eigentlichen CSP-Modell statisch ist. Der Versand von Nachrichten erfolgt laut Vajda[16] über sogenannte Communication Channels orientiert sich aber an dem Prinzip Share memory by communicating. Dies wird gewährleistet, indem über die Channels nur Referenzen auf Daten oder andere Channels, oder ganze Channels, aber keine Daten verschickt werden können. Damit sind Nachrichten auch das Hauptmittel zur Synchronisation zwischen Prozessen. 3.2 Actor-Modell basierte Programmiersprachen Im Actor-Modell erfolgt die Kommunikation, wie in Programming Many-Core Chips [16] beschrieben, asynchron. Im Gegensatz zum CSP Modell kann hier aber von vornherein jeder Actor mit jedem anderen Nachrichten austauschen. Ausgehend von der Art der Nachricht, deren Inhalt und dem internen Zustand des Actors, werden dann Operationen ausgeführt. Anschließend können nahezu beliebig viele Antworten versendet werden. Während die Zustellungsreihenfolge der Nachrichten nicht total sein muss, ist es die Eingangsreihenfolge von Nachrichten sehr wohl - man spricht hier beim Eintreffen einer Nachricht von einem Event. Ein Event versetzt nun durch die Ausführung der ausgelösten Operationen den Actor in einen neuen internen Zustand. Zu beachten ist hierbei, dass Events ungeordnet auftreten können. Laut [16] treten sie dann parallel ein, was dazu führt, dass mehrere neue lokale Zustände von Actors asynchron erzeugt werden können. Actors sind in diesem Programmiermodell auch in der Lage, wieder neue Actors zu generieren, wodurch das System dynamisch wird. Es wird allerdings keine zentrale Einheit unterstützt, die den alleinigen vollständigen Überblick über alle Komponenten des Systems hat. Programmiersprachen, die das Actor- Modell realisieren, erzeugen also verteilte Systeme Scala Die Programmiersprache Scala hat sowohl Eigenschaften funktioneller als auch objektorientierter Programmiersprachen und wird häufig als Baukasten für neue Programmiersprachen verwendet, da sie Programmierung von Many-Cores 7

8 sehr leicht erweiterbar ist. Dadurch dass sie zu Java-Bytecode kompiliert und in der Java Virtual Machine (JVM) ausgeführt wird, kann sie auf jeder beliebigen Plattform eingesetzt werden, sofern Java installiert ist. Das Actor-Modell wird in Scala umgesetzt, indem die Klasse Actor implementiert und die Methode Actor.act() überschrieben wird. Durch das Kompilieren zu Java-Bytecode werden die Actors als Java- Threads realisiert und als Threads von der JVM gescheduled. Die Actors können im Gegensatz zum reinen Actor-Modell sowohl asynchron als auch synchron miteinander kommunzieren, wobei der Sender bei synchroner Kommunikation so lange blockiert wird, bis die Antwort (reply) des Empfängers angekommen ist. 3.3 Task-basierte Ansätze Im Task-basierten Programmiermodell muss der Entwickler selbst parallelisierbare Befehle und Codeblöcke identifizieren und kennzeichnen. Das Run-time-System erstellt dafür Tasks und übernimmt das eigentliche Scheduling auf die vorhandene Hardware. Für den Programmierer bleibt damit transparent, WAS parallelisiert wird, aber er braucht sich selbst nicht mit dem Scheduling und Parallelisieren beschäftigen. Die Tasks werden in einer oder mehreren Queues verwaltet, von denen die eingesetzten Prozessoren Arbeit stehlen können, wenn sie nichts zu tun haben. Für die Verwaltung der Queues wird aber implizit ein shared memory gefordert X10 X10, ist ein objektorientierter Ansatz, der genau wie Scala zu Java-Bytecode kompiliert wird, aber auf Task basiertes Programmieren unterstützt statt dem Actor-Modell. Hier wird, wie in Programming Many-Core- Chips [16] beschrieben, mit dem PGAS Modell (partitioned global address space) gearbeitet. Die Umgebung wird also in Form mehrerer places verwaltet. Ein place ist dabei ein Prozessor mit eigenem Speicher. Objekte wie Integer, String, boolean oder Ähnliches befinden sich in einem bestimmten place. Activities (so heißen hier Tasks) können nur lesend oder schreibend darauf zugreifen, wenn sie sich im place befinden und dort ausgeführt werden. Wird eine activity in einem anderen place ausgeführt, muss sie erst in den gewünschten place verschoben werden. Arrays oder Listen, also Container im Allgemeinen können allerdings über mehrere places verteilt sein laut [16]. Liegen beispielsweise die Stellen 0 bis 2 eines Arrays in place A, die Stellen 3, 4, 5, und 6 in place B und die Stellen 7 bis 9 in place C, so kann die Abarbeitung eines Schleifendurchlaufs auf mindestens 3 activities verteilt werden, die jeweils für einen place zuständig sind. Die einzelnen activities können ihre Objekte abarbeiten, ohne zwischendurch in einen anderen place verschoben werden zu müssen, weshalb sie auch parallel ausgeführt werden können. Diese Methode erleichtert die Parallelisierung von Tasks deutlich. 4 Häufig verwendete Techniken der Parallelisierung Vergleicht man gängige Programmiersprachen, wie die hier dargestellten, so kann man einige Konstrukte herausfiltern, die häufig verwendet werden. Dazu gehört etwa die Parallelisierung von Schleifen, die Intel, OpenMP und SPAP verwenden. In Intel Thread Building Blocks werden spezielle keywords wie z.b. parallel for, parallel do oder parallel reduce verwendet, in SPAP heißt ein parallel for dann forall. OpenMP hingegen weist mit eigenen Compiler-Direktiven darauf hin, die folgender Maßen aufgebaut sind: Programmierung von Many-Cores 8

9 #pragma omp parallel for (Beispiel aus Programming Many-Core Chips [16]) Compiler-Direktiven an sich werden ebenfalls häufig eingesetzt und oft mit eigens dafür entwickelten Umgebungsvariablen verwendet.. Von den vorgestellten Programmiersprachen finden sie nicht nur in OpenMP Anwendung sondern auch in OpenACC. Je nachdem, ob OpenACC mit Fortran oder mit C kombiniert wird, ergeben sich folgende Beispiele: Fortran:!$acc <Anweisung> C: #pragma acc <Anweisung> (Beispiel aus Programming Many-Core Chips [16]) Eine weitere Methode, die viel Anwendung findet, ist der Einsatz von dedizierten neuen Schlüsselwörtern. Bei Intel Cilk gibt es zum Beispiel genau drei, cilk, spawn und sync, bei X10 gibt es mehrere, u.a. async, finish, atomic oder clocked. Gerade bei Programmiersprachen, die das Actor-Modell realisieren, kommt es häufig auch vor, dass spezielle Oberklassen von einer eigenen Klasse implementiert werden und deren ausführende Methoden überschrieben werden müssen. Dies ist bei Intel Thread Building Blocks und Microsoft Task Parallel Library die Klasse Task mit der Methode Task.execute(), oder bei Scala die Klasse Actor mit der Methode Actor.act(). 5 Programmierumgebungen und Bibliotheken Neben alleinstehenden Programmiersprachen, die sich für die Entwicklung paralleler Anwendungen eignen, gibt es auch ganze Entwicklungsumgebungen, die speziell darauf ausgelegt wurden. Einige davon werden im Folgenden näher vorgestellt im Hinblick auf ihre Einsatzgebiete, Vor- und Nachteile. Aber auch zwischen den einzelnen Umgebungen muss unterschieden werden zwischen solchen, die speziell für ein Betriebssystem oder für den Einsatz auf Hardware eines bestimmten Herstellers optimiert wurden und solchen, die auf allen CPU- oder GPU-Architekturen laufen, sofern diese gewisse Kriterien erfüllen. Programmierung von Many-Cores 9

10 Abbildung 7 Die hier vorgestellten Programmiersprachen und -umgebungen können zum Beispiel nach ihrem Hardware-Einsatzgebiet, ihrem Programmiermodell und danach eingeordnet werden, ob sie speziell entwickelt wurden oder für alle CPU und/oder GPU Architekturen anwendbar sein sollen. Abbildung 7 zeigt eine Möglichkeit, wie die in dieser Arbeit vorgestellten Programmiersprachen und Umgebungen eingeordnet werden könnten. 5.1 Plattformspezifische Programmierumgebungen Die Marktführer in den Bereichen Betriebssysteme und Prozessor- oder Graphikkartentechnologie wie Apple, Microsoft, Intel, oder NVIDIA haben eigene Ansätze zur optimierten Parallelisierung entwickelt, die sich vor allem darin unterscheiden, ob sie für eine Plattform spezialisiert wurden oder für eine bestimmte Komponente. Intels Lösungen Thread Building Blocks und Cilk Plus sind speziell auf die Intel CPUs ausgelegt, während NVIDIA CUDA TM für die Programmierung von Anwendungen entwickelt wurde, die auf deren Graphikkarten laufen sollen. Durch die Spezialisierung ist ein hoher Grad an Parallelisierung erreichbar, die Programme sind aber an die verwendete Plattform gebunden und kaum portierbar Intel Cilk Intel Cilk und Cilk Plus bieten dabei eine Task-basierte Umgebung, bei der die Tasks mit dem Kontext des Parent-Tasks initiiert werden. Die Verwaltung der Tasks erfolgt in einer Queue mit Hilfe des work-stealing- Algorithmus, sodass Prozessoren, wenn sie Kapazität frei haben, sich selbst einen Task von der Queue holen und bearbeiten können. Nachdem Tasks in der Lage sind, ihrerseits Tasks zu erzeugen, entsteht hier ein dynamisch aufbaubarer directed acyclic graph (DAG) mit G = (V, E). V ist die Menge aller Knoten v, wobei Programmierung von Many-Cores 10

11 ein Thread einem Knoten entspricht, und E ist die Menge aller Kanten e, wobei e der Kontext ist, wie es auch von Vajda in Programming Many-Core Chips [16, Kapitel 9.2.1] erläutert wurde. Die Berechnung der Fibonacci Zahlen wird auch in [16] als Beispiel für die Programmierung mit Cilk und den Einsatz der hier eingeführten Schlüsselwörter gewählt. Lässt man die keywords cilk, spawn und sync weg, erhält man ein voll ausführbares sequentielles C Programm. 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; } } Apple: Grand Central Dispatch Auch der Hardware- und Betriebssystem- Hersteller Apple hat eine Eigenentwicklung vorzuweisen. Grand Central Dispatch basiert ebenfalls auf Tasks, die hier aber in mehreren Queues unterschiedlicher Hierarchieebenen und Prioritäten verwaltet werden. Wie Abbildung 7 zeigt, gibt es hier eine global main queue, die die oberste Hierarchieebene darstellt. Danach gibt es 3 global asynchrone queues mit hoher, mittlerer und niedriger Priorität. Zuletzt gibt es nach Bedarf benutzerspezifizierte serielle Queues in solcher Anzahl, wie sie vom Benutzer benötigt werden. Grand Central Dispatch baut auf C auf, verzichtet aber laut Vajda[16] auf manche Konstrukte und führt dafür einige eigene Abbildung 8 Thread-Verwaltung in Grand Central Dispatch in Anlehnung an Programming Many-Core Chips [16, Kapitel 9.2.2] Compiler-Erweiterungen ein, wie z.b. blocks. Blocks funktionieren ähnlich wie private Methoden in Java und werden folgendermaßen erzeugt: int (hitchhiker)(int) = ^(int n){return n*42} (Beispiel aus [16, Kapitel 9.2.2]) Das ^ weist dabei den in geschweiften Klammern stehenden Code als block aus, wobei die Ausführung eines blocks auch auf mehrere Queues verteilt werden kann Microsoft Task Parallel Library Microsoft Task Parallel Library ist eine weitere Task-basierte spezielle Programmierumgebung. Sie ist seit Version 4.0 Teil des.net Frameworks und deshalb sehr weit verbreitet. Hier arbeitet der Scheduler auf einem Programmierung von Many-Cores 11

12 Thread-Pool und mehreren Thread-local Queues. Mit Hilfe des work-stealing-algorithmus können auch in TPL die Prozessoren Task aus diesem Thread-Pool stehlen. In TPL wird task-basiertes Programmieren durch Implementierung der Klasse Task und Overriding der Methode Task.execute() realisiert. Wird ein Task ausgeführt, der Daten von einem Task benötigt, der in der Queue erst später ausgeführt werden würde, so kann dieser Task vorgezogen werden. Der in der Ausführung befindliche erste Task kann dann mit den Ergebnissen des vorgezogenen Tasks durch dieses sogenannte In-lining schneller zu Ende gebracht werden, wie Vajda in [16, Kapitel 9.2.4] erläutert. Wie in [16] auch dargestellt wird, verwendet TPL auch das Prinzip der Futures, um Parallelität zu modellieren. int s1 Result = S1(input_value); //Tasks S2, S3 und S4 werden als Futures erzeugt Task<int> s2 Result = Task.Factory.StartNew<int>( () => S2(s1Result)); Task<int> s3 Result = Task.Factory.StartNew<int>( () => S3(s1Result)); Task<int> s4 Result = Task.Factory.StartNew<int>( () => S4(s1Result)); //wenn diese 3 Tasks fertig sind wird das //Gesamtergebnis in Task S5 berechnet int final_result = Task.Factory.ContinueWhenAll<int, int>( new[] (s2result, s3result, s4result), (tasks) => S5(s2Result.Result, s3result.result, s4result.result)); Abbildung 9 Der aus dem Code-Beispiel zu Futures in TPL entstehende Taskgraph. Wie in diesem an Vajdas Code in Abbildung 9.7 [16] orientierten Beispiel dargestellt, werden Futures mit Task.Factory.StartNew<>() erzeugt und können dann parallel ausgeführt werden. Das Ergebnis wird in einem separaten Task berechnet, sodass sich der in Abbildung 8 dargestellte, an Abbildung 9.7 aus [16] angelehnte Taskgraph ergibt. Im Bedarfsfall gibt es bei Task Parallel Library auch die Möglichkeit einen Task abzubrechen. Eine Synchronisation zwischen mehreren Tasks muss allerdings explizit erfolgen, wie in obigem Beispiel mit Task.Factory.ContinueWhenAll<>(). 5.2 One step higher: Cross-Plattform Entwicklungsumgebungen Neben den eben vorgestellten Plattform-spezifischen Entwicklungsumgebungen gibt es auch portable Lösungen, die sich besonders für Anwendungen eignen, die auf jeder beliebigen CPU oder GPU, oder auch auf beidem laufen sollen. Beispiele solcher Anwendungen sind, wie im Artikel SPAP: A Programming Language for Heterogenous Many-Core Systems [17, Seite 2, linke Spalte] als Beispielimplementierungen für SPAP angegeben, AES Verschlüsselung, JPEG Kodierung oder eine lexikographische HTML Analyse OpenMP Wie es bei den eben vorgestellten Plattform-spezifischen Entwicklungsumgebungen Task-basierte Lösungen gibt, arbeitet auch OpenMP mit dem Konzept der Tasks. Zusätzlich ist OpenMP data-parallel, wie man Programmierung von Many-Cores 12

13 Kapitel aus Programming Many-Core Chips [16] entnehmen kann und bringt einen erweiterten Compiler-Befehlssatz mit. Die Tasks werden hier mit Hilfe mehrerer Mechanismen parallelisiert. Die data sharing attributes shared und private regeln den Zugriff auf Variablen wie private und public in Java. Synchronization primitives sind Direktiven, die ein explizites Scheduling der Tasks an dieser Stelle erfordern. Außer an diesen Stellen wird bei OpenMP kein Scheduling zugelassen. Tasks können aber auch verschachtelt werden, was sogenannten nested parallelism erzeugt. Der Thread-Pool, der zur Verwaltung der Tasks dient, kann selbst auch sehr leicht verwaltet und nach Bedarf in seiner Größe angepasst werden. Die Dimensionierung wird dabei über das Setzen einer speziellen Umgebungsvariablen vorgenommen, wie das folgende Beispiel aus Programming Many-Core Chips [16] zeigt. n = 2000; // Dies ist eine der OpenMP spezifischen Direktiven. Sie erzeugt eine parallelisierbare // Schleife. #pragma omp parallel for for (i=0; i < n; i++) { z[i] = x[i] * y[i]; } // Kompilierung und Ausführung können folgendermaßen erfolgen: setenv OMP_NUM_THREADS 10 cc xopenmp mycode.c a.out Der Befehl setenv bedeutet dass die Umgebungsvariable OMP_NUM_THREADS auf den Wert 10 gesetzt werden soll. OMP_NUM_THREADS definiert dabei die Anzahl der Threads, also die Dimension des Thread- Pools. Obwohl der Thread-Pool vom Entwickler verwaltet und dimensioniert werden kann, ist dennoch das Run-time-System für das Scheduling der Tasks und deren Zuweisung auf die vorhandenen Prozessoren zuständig. Dadurch eignet sich OpenMP besonders gut für Programme, die auf CPUs laufen sollen, aber weniger gut für GPU-Anwendungen OpenHMPP OpenHMPP hingegen wurde speziell für den Einsatz auf Graphikkarten entworfen, lehnt sich aber unter anderem an OpenMP an, wie man der Homepage von CAPS [14] sehr gut entnehmen kann. OpenHMPP arbeitet ebenfalls mit Compiler-Direktiven, die aber eher remote procedure calls auf den Accelerator, also die Graphikkarte, beschreiben, denn den Umgang mit nachfolgenden Anweisungen näher zu spezifizieren. Der Entwickler muss bei OpenHMPP die gesamte Hardware und damit auch das Scheduling selbst verwalten, weshalb sich der Einsatz hauptsächlich auf GPUs beschränkt. Der Fokus liegt bei OpenHMPP aber noch mehr auf der Portabilität zwischen den einzelnen Graphikkarten-Architekturen, wie auf der Internetseite [14] dargestellt wird OpenCL Im Gegensatz zu OpenMP und OpenHMPP kann OpenCL für beide Hardware-Komponenten eingesetzt werden und eignet sich deshalb besonders gut zur Entwicklung sogenannter host+accelerator Programme. Der host ist dabei die CPU, der accelerator wieder die Graphikkarte. OpenCL ist eine weitere task-basierte Programmierumgebung, ein Task ist hier aber ein Kernel mit genau einem Arbeitspaket. Kernel an sich Programmierung von Many-Cores 13

14 können nicht als host-funktion dienen, sie können also keine weiteren Tasks erzeugen, deshalb sind OpenCL Programme statisch und dynamisches task-paralleles Programmieren ist kaum möglich. Die Ausführung eines OpenCL-Programms erfolgt auf command queues. Die verwendete Hardware muss diese queues selbst auf die OpenCL devices verteilen, wobei ein OpenCL device eine logische Einheit bestehend aus mehreren Recheneinheiten darstellt. Dadurch dass es erforderlich ist, dass die Hardware das Scheduling selbst übernimmt, scheiden GPUs aus, die keinen eigenen Support für Thread-Verwaltung bieten. Wie im eigentlichen Task-basierten Modell erfolgt auch hier die Kommunikation asynchron, es werden aber zwei Möglichkeiten unterschieden. Nachrichten können sowohl in-order versendet werden, also seriell, als auch out-of-order SPAP SPAP (Same Programm for All Processors) wurde speziell dafür entwickelt, auf allen CPUs und GPUs einsetzbar zu sein und dem Programmierer eine Möglichkeit zu geben, sein Programm nur einmal schreiben zu brauchen und auf jeder beliebigen Maschine ausführen zu können. Eigens dafür definierte Container garantieren eine besonders gute Parallelisierbarkeit von z.b. Arrays und Listen, deren Initialisierung leicht verständlich ist und der von Java sehr ähnlich sieht, wie man an einem Beispiel aus dem Artikel zu SPAP [17] schnell erkennen kann: auto pos_i = new int<>; // definiert ein neues leeres Array Innerhalb eines Prozessors kann Parallelisierung mit Hilfe der.push_back() Funktion für Container erreicht werden. Dabei werden die Resultate der parallel abgearbeiteten Container-Stellen, laut Hou [17], in derselben Reihenfolge in den Container zurück geschrieben wie bei sequentieller Ausführung. Sollen Teile eines Programms auf mehrere Prozessoren parallelisiert werden, so kann dies mit dem Methoden-Aufruf distribute() {...} erreicht werden. Bei dieser Art der Parallelisierung ist aber eine explizite Synchronisation über den Aufruf serialize() {...} notwendig, der dann innerhalb des distribute() Blocks erfolgt. Die SPAP Befehle werden bei Programmausführung automatisch vom Compiler durch die effizienteste, ihm zur Verfügung stehende Implementierung ersetzt. Teile von Tasks werden dann an Prozessoren vergeben, sobald diese frei sind, wobei die Größe dieser Teile entweder durch die Kapazität des Prozessors bestimmt ist oder falls nötig auch vom Entwickler direkt angegeben werden kann. 6 Aussichten Die vielen unterschiedlichen Hardware-Architekturen stellen einige Anforderungen an moderne Programmiersprachen, wie in den vorangegangenen Kapiteln erläutert wurde. Dies spiegelt sich in der Vielzahl der Lösungen, von denen einige ebenfalls kurz vorgestellt und verglichen wurden. Aber trotz der vielfältigen Auswahl an Programmiersprachen und Entwicklungsumgebungen, die sich aus den Anforderungen heraus gebildet haben, gibt es immer noch einige Aspekte, in denen sich diese Tools noch verbessern können und müssen. In den meisten Sprachen muss beispielsweise der Entwickler sein Programm immer noch von Hand so umschreiben, dass ein höherer Grad an Parallelisierung erreicht werden kann. Der nächste Entwicklungsschritt für Programmierumgebungen könnte also sein, dass dies automatisiert wird. Programmierung von Many-Cores 14

15 Ein weiterer Punkt ist die Portabilität von Programmen, die eine zunehmend wichtigere Rolle spielt, bei den vorgestellten Lösungen aber nicht, oder nur teilweise erreicht wird. Mit OpenCL und SPAP wurde bereits ein wichtiger Schritt in diese Richtung getan. Hier kann aber auch noch viel erreicht werden, indem zum Beispiel high-level Programmiersprachen wie Java mit entsprechenden Parallelisierungsmechanismen versehen werden, da aktuell nur relativ Hardware-nahe Programmiersprachen wie C, Erlang oder Scala als Basis dienen. Im Bereich der Hardware wird der Trend in den nächsten Jahren dahin gehen, dass noch mehr Kerne verbaut werden als bisher und so die Rechenleistung noch weiter gesteigert wird. NVIDIA hat vor kurzem bereits angekündigt mit Volta eine Graphikkarte auf den Markt bringen zu wollen, die eine Bandbreite von bis zu 1TB/s erreichen soll. Dafür wird eine neue Technologie eingesetzt, die den Arbeitsspeicher in die dritte Dimension versetzt, der sogenannte Stacked DRAM. Programmierung von Many-Cores 15

16 Referenzen (mit Unterseiten) tbs-of-memory-bandwidth/ 16 Vajda, A., Programming Many-Core Chips, Kapitel 8-10, Erscheinungsdatum 2011, Springer Verlag 17 Hou, Q.; Zhou, K.; Guo, B., SPAP: A Programming Language for Heterogeneous Many-Core Systems Programmierung von Many-Cores 16