OpenCL mit Aparapi. Seminararbeit. Studiengang: Scientific Programming. 1. Betreuer: Prof. Ulrich Stegelmann

Transkript

1 Seminararbeit Studiengang: Scientific Programming 1. Betreuer: Prof. Ulrich Stegelmann 2. Betreuer: Dipl.-Inform. Tobias Rötschke Vorgelegt von: Lukas Abels-Vehns SOPTIM AG Im Süsterfeld 5-7 D Aachen Telefon: + 49 (0) Dietrich-Oppenberg-Platz 1 D Essen Telefon: +49(0) Internet: info@soptim.de

2

3 / Lukas Abels-Vehns Seite 3 Inhaltsverzeichnis Seite 1 Einleitung 5 2 GPGPU (General-purpose computing on Graphics Processing Units) Geschichte Einsatzgebiete Aufbau einer GPU OpenCL OpenCL Architektur Wichtige Begriffe Host Device, Compute Units und Processing Elements Kernel Command Queues Context Platform Model Execution Model Memory Model Programming Model Data Parallel Model (datenparalleles Modell) Task Parallel Model (aufgabenparalleles Modell) OpenCL Framework 13 3 Aparapi Ausführungsmodi Vorraussetzungen Nutzung von Aparapi Expliziter Speichertransfer Schleifen mit bekannter Iterationsanzahl Vergleich zu anderen Bibliotheken Beschränkungen Datentypen Felder Arrays Methoden Weitere Beschränkungen 20

4 / Lukas Abels-Vehns Seite 4 4 Anwendungsbeispiel: Aggregation von Zeitreihen Testaufbau Testauswertung 23 5 Zusammenfassung und Ausblick 26 6 Literaturverzeichnis 27 7 Abbildungsverzeichnis 28

5 / Lukas Abels-Vehns Seite 5 1 Einleitung Die vorliegende Seminararbeit behandelt das Thema OpenCL mit Aparapi, einer API zur einfachen Benutzung der Rechenleistung von Grafikkarten für nicht-grafische Zwecke in Java. Die angegebenen Beispielprogramme sind in der Programmiersprache Java mit Hilfe der Eclipse Entwicklungsumgebung und der dargestellte Graph mit Scilab erstellt worden. In der heutigen Zeit kann der Bedarf nach höherer Rechenleistung nicht mehr durch das Erhöhen der Taktfrequenz einer CPU befriedigt werden. Eine Lösung für dieses Problem liegt in der Rechenleistung von Grafikchips (GPU, Graphics Processing Unit) auf modernen Grafikkarten. Diese sind durch ihre spezielle Architektur besser für hoch parallele Berechnungen geeignet, als eine gewöhnliche CPU. Um die Rechenleistung eines Grafikchips zu verwenden, mussten Schnittstellen geschaffen werden, die die Kommunikation mit der Grafikkarte ermöglichen und zugleich Entwicklern möglichst komfortable Wege eröffnen, die speziellen Fähigkeiten eines Grafikchips zu nutzen. Der Trend zur Nutzung von Grafikkarten ist deutlich im Bereich des High Performance Computing zu erkennen. Der momentan Zweitplatzierte auf der Liste der Top 500 Supercomputer, der Tianhe- 1A, besitzt eine Kombination aus CPUs und GPUs und hat eine Leistung von 2.57 Petaflop/s (flop = floating point operation) [TOP500]. In Kapitel 2 dieser Arbeit wird das Thema des General-purpose computing on Graphics Processing Units (GPGPU) vorgestellt. Dabei wird auf die Geschichte des Themas eingegangen, sowie im Großteil des Kapitels auf OpenCL, ein offener Standard für GPGPU. In Kapitel 3 wird die Java Bibliothek Aparapi beschrieben, die die Nutzung von OpenCL für die Java Programmiersprache ermöglicht. Anschließend wird in Kapitel 4 ein Anwendungsbeispiel von OpenCL mit Aparapi anhand der Aggregation von Zeitreihen dargestellt. Kapitel 5 bietet abschließend eine Zusammenfassung der Arbeit sowie einen Ausblick auf andere Themen, die auf diese Arbeit aufbauen.

6 / Lukas Abels-Vehns Seite 6 2 GPGPU (General-purpose computing on Graphics Processing Units) 2.1 Geschichte Die Entwicklung der Computerspieleindustrie zwang die Hersteller von Grafikkarten immer leistungsfähigere Grafikchips mit schnellem Speicher herzustellen. Jedoch wurde dieses große Potenzial an Rechenleistung nur in Grafikanwendungen wie Spielen benutzt und kam in anderen Fällen nicht zum Einsatz. Die Ansprüche von Software aus anderen Bereichen, in denen es mehr auf die Menge an Operationen pro Zeiteinheit als auf die Ausführungsgeschwindigkeit einer Operation ankommt, an die Leistungsfähigkeit eines Rechners konnten aber nicht mehr nur durch die CPU gedeckt werden. Dies lässt sich deutlich bei zum Beispiel wissenschaftlichen Anwendungen sehen, die dünn besetzte Matrix-Operationen durchführen [GARKIRK10]. Daher bestand der Bedarf, die Leistung von Grafikchips auch für nicht-grafische Berechnungen bereitzustellen. NVIDIA schuf 2006 für diesen Zweck die Programmierplattform CUDA. Durch CUDA ist es möglich, NVIDIA Grafikchips für allgemeine Berechnungen zu benutzen. CUDA ist somit die erste bedeutende Bibliothek für GPGPU. Auch andere Grafikkartenhersteller entwickelten in diesem Feld eigene Plattformen, bis Ende 2008 durch einen Zusammenschluss von einigen Firmen der offene Standard OpenCL erstellt wurde. 2.2 Einsatzgebiete Die Einsatzgebiete, in denen GPGPU einen Vorteil erbringt, sind vielfältig. Besonders die Bereiche Ingenieurswesen, Architektur und Wissenschaft profitieren von der hohen Leistung bei numerischen Berechnungen für die akkurate und schnelle Darstellung von Simulationen. Aber auch Bereiche wie digitale Medien und Unterhaltung erzielen Performancegewinne durch den Einsatz von GPGPU bei der High-End Visualisierung von Daten, der Echtzeit Video Verarbeitung oder physikalischen Simulationen von 3D-Modellen [AMD10]. Ein denkbarer Einsatz von GPGPU bei der SOPTIM AG ist die Aggregation, Analyse und Bepreisung von Energiemessdaten. Dies wird auch in einem späteren Kapitel an einem Anwendungsbeispiel veranschaulicht. 2.3 Aufbau einer GPU Die große parallele Rechenleistung einer GPU ergibt sich durch ihre Architektur. Im Gegensatz zu modernen Multicore-Prozessoren mit 2 bis 8 Kernen, besitzt eine GPU über 100 Kerne. Im nachfolgenden Bild ist ein schematischer Vergleich einer CPU und GPU zu erkennen. Eine CPU

7 / Lukas Abels-Vehns Seite 7 hat einen größeren Cache und Befehlssatz sowie Speicher, dafür aber nur wenige ALUs (Arithmetisch Logische Einheit). Eine GPU besitzt viele ALUs, die nur einen kleinen Befehlssatz, Cache und Speicher zur Verfügung haben. Dadurch ist es der GPU möglich, viele Berechnungen parallel durchzuführen. Abbildung 2.1: Schematischer Vergleich der Architektur einer CPU und GPU 2.4 OpenCL OpenCL (Open Computing Language) ist ein offener Standard für plattformunabhängiges, verteiltes Rechnen. Die in der OpenCL spezifischen Sprache OpenCL C geschriebenen Programme, die sogenannten Kernel, können auf die verschiedenen OpenCL-fähigen Geräte, zu denen CPUs und GPUs gehören, verteilt werden. OpenCL ermöglicht entsprechenden Anwendungen somit einen großen Performancegewinn durch paralleles Rechnen. OpenCL wurde ursprünglich von Apple entwickelt und zusammen mit Firmen wie unter anderen AMD, NVIDIA, Intel und IBM in einer ersten Version ausgearbeitet [OPENCL]. Die fortlaufende Entwicklung von OpenCL wird unter der Leitung der Khronos Group, einem Industriekonsortium aus über 100 Konzernen, durchgeführt, die ebenfalls für die Standardisierung von ähnlichen Schnittstellen wie OpenGL (Open Graphics Library) verantwortlich ist [KHRONOS]. OpenCL C basiert auf der ISO standardisierten Programmiersprache C und ist durch einige Datentypen und Funktionen für parallele Berechnungen erweitert worden. Im Vergleich zu C gibt es jedoch einige Einschränkungen. So ist es beispielweise nicht möglich, Pointer auf Funktionen, Rekursion oder Arrays mit variabler Länge zu benutzen [OPENCL Kapitel 6.8]. Für die Nutzung von OpenCL sind einige Vorraussetzungen zu erfüllen. Die erste ist eine Implementierung des Standards im Betriebssystem. Das erste Betriebssystem, das OpenCL

8 / Lukas Abels-Vehns Seite 8 implementierte, war Mac OS X 10.6 von Apple aus dem Jahre 2009 [APPLE09]. Inzwischen besitzen auch Windows und einige Linux-Distributionen wie Ubuntu OpenCL-Implementierungen. Des Weiteren ist das Vorhandensein von OpenCL kompatibler Hardware, wie zum Beispiel GPUs und CPUs, eine Vorraussetzung. Die Grafikchips der beiden größten Hersteller, NVIDIA und AMD, sind inzwischen alle OpenCL kompatibel. Abschließend müssen noch OpenCL Treiber für die jeweilige Hardware auf dem System installiert sein. Die Vorteile, die ein offener Standard wie OpenCL gegenüber proprietären Frameworks wie CUDA besitzt, sind zum Beispiel die größere Auswahl an unterstützen Plattformen oder die bessere Entwicklung und Unterstützung von einer Vielzahl von Firmen und Personen. Diese Punkte werden durch das breite Konsortium an beteiligten Firmen gewährleistet, die ebenfalls die Portabilität von Code zwischen ihren Plattformen vereinfachen [AMD10]. Die Stärken von OpenCL und die zukünftige Entwicklung und Verbreitung des offenen Standards führen auch zur teilweisen Öffnung von proprietären Alternativen, wie zum Beispiel die Veröffentlichung des Quellcodes des CUDA Compilers von NVIDIA [NVIDIA11]. 2.5 OpenCL Architektur Die Architektur von OpenCL spaltet sich in vier Modelle auf. Das Platform Model, Execution Model, Memory Model und Programming Model. Die Informationen dieses Abschnitts stammen aus der OpenCL 1.0 Spezifikation, zu finden unter [OPENCL] Wichtige Begriffe Host Der Host ist laut OpenCL Spezifikation das Gerät, auf dem die Host Applikation läuft und das mit einem oder mehreren OpenCL-fähigen Geräten, den so genannten Devices, verbunden ist. Die OpenCL Host Applikation sendet Befehle vom Host Device aus, um Berechnungen auf den Processing Elements der verbundenen OpenCL Devices auszuführen Device, Compute Units und Processing Elements Ein Device ist ein OpenCL-fähiges Gerät, welches aus einem oder mehreren Compute Units besteht. Diese Compute Units entsprechen den Kernen auf einer CPU oder GPU. Jede Compute

9 / Lukas Abels-Vehns Seite 9 Unit ist unterteilt in ein oder mehrere Processing Elements, die letztendlich die Berechnungen auf dem Device ausführen Kernel Ein Kernel stellt das Programm dar, welches auf dem OpenCL Device ausgeführt werden soll. Die Kernels müssen auf der ausführenden Maschine kompiliert werden, da nur dann die spezifischen Bedingungen des Systems bekannt sind. Der Quellcode der Kernel ist in die Host Applikation eingebettet oder liegt der Host Applikation in separaten Dateien vor Command Queues Die Command Queues (Befehlswarteschlangen) in OpenCL werden dazu verwendet, um anstehende Befehle an die mit der Host Applikation verbundenen Geräte zu übermitteln. Die verschiedenen Typen von Befehlen sind die Ausführung eines Kernel, der Transfer von Daten zwischen verschiedenen Speicherobjekten, sowohl auf dem OpenCL Device als auch auf dem Host Device, und Synchronisations-Befehle, die die Abfolge von Befehlen regeln Context Der von der Host Applikation definierte Context für die Ausführung von Kernels umfasst folgende Ressourcen: 1. Devices: Die mit dem Host verbundenen OpenCL Devices 2. Kernels: Die OpenCL Funktionen, die auf den Devices ausgeführt werden sollen 3. Program Objects: Der Programmcode der Kernels und die dazugehörigen ausführbaren Dateien, die die Kernels implementieren. 4. Memory Objects: Eine Menge von Speicherobjekten, die sowohl für den Host als auch für die OpenCL Devices sichtbar ist. Diese Speicherobjekte enthalten Werte, die von den Kernel-Instanzen bearbeitet werden können.

10 / Lukas Abels-Vehns Seite Platform Model Das Platform Model von OpenCL ist unterteilt in den Host, der mit den Devices verbunden ist. Diese sind wiederum unterteilt in mehrere Compute Units mit mehreren Processing Elements. Die Host Applikation steuert den gesamten Ablauf der Anwendung. Der wichtige Punkt bei diesem Modell ist der Übertragungsweg zwischen Host Device und Compute Devices. Die Datentransfergeschwindigkeit von Host zu Compute Device ist wesentlich langsamer als intern im Compute Device. Daher ist darauf zu achten, dass ausreichend Daten in einem Schritt vom Host übertragen werden, damit die Processing Elements genug Berechnungen ausführen können, bevor wieder Daten zum Host übertragen werden müssen. Wenn dieses Problem nicht behandelt wird, kann der Geschwindigkeitsgewinn durch die Benutzung der parallelen Compute Devices leicht durch die Übertragungszeit wieder ausgeglichen werden. Abbildung 2.2: Plattform Modell aus der OpenCL Spezifikation Execution Model Die Ausführung eines OpenCL Programms besteht aus zwei Teilen. Die Host Applikation, die auf dem Host Gerät ausgeführt wird und die Kernel, die auf den OpenCL Geräten ausgeführt werden. Dabei organisiert die Host Applikation die Ausführung der Kernel über die Befehlswarteschlange. Wenn ein Kernel zur Ausführung auf das OpenCL Gerät übertragen wird, wird ein Indexraum angelegt. Für jeden Punkt des Indexraums gibt es eine Instanz des auszuführenden Kernels. Eine solche Instanz heißt Work-Item und ist durch den ihm zugewiesenen Punkt im Indexraum, seine globale ID, eindeutig identifizierbar. Jede Kernel-Instanz führt den gleichen Code aus, jedoch

11 / Lukas Abels-Vehns Seite 11 können der spezifische Ablauf des Kernel Codes und die zu bearbeitenden Daten für jedes Work- Item variieren. Des Weiteren sind Work-Items in Work-Groups eingeteilt. Eine Work-Group ist über eine globale Work-Group ID identifizierbar und jedes Work-Item einer Work-Group hat eine für die Work-Group lokale ID. Demzufolge ist ein Work-Item entweder über seine globale ID oder über die Kombination von Work-Group ID und lokaler ID identifizierbar. Der Indexraum ist ein N-Dimensionaler Raum, wobei N entweder 1,2 oder 3 ist. Die IDs eines Work-Items sind N-Dimensionale Tupel, die einzelnen Werte dieser Tupel liegen für die globale ID zwischen 0 und der Maximalanzahl der Elemente in der Dimension minus 1 und lokale ID innerhalb einer Work-Group wird durch die Größe der Work-Group beschränkt Memory Model Das Speichermodell von OpenCL beschreibt vier unterschiedliche Speicherregionen. Globaler Speicher: Auf diese Region haben alle Work-Items Lese- und Schreibrechte. Konstanter Speicher: In dieser Region werden konstante Werte abgelegt, auf die Work- Items nur Lesezugriff haben. Der konstante Speicher wird vom Host angelegt und initialisiert. Lokaler Speicher: Jede Work-Group hat eigenen lokalen Speicher. In dieser Region werden Werte gespeichert, die von den Work-Items einer Group geteilt werden. Privater Speicher: Jedes Work-Item hat eigenen privaten Speicher. In dieser Region definierte Variablen sind für andere Work-Items nicht sichtbar. Der konzeptionelle Aufbau und Zusammenhang zwischen Speicher und Plattform Modell wird durch die folgende Grafik verdeutlicht:

12 / Lukas Abels-Vehns Seite 12 Abbildung 2.3: OpenCL Memory Model Programming Model Data Parallel Model (datenparalleles Modell) Das Data Parallel Model beschreibt eine Berechnung als Abfolge von Befehlen, die auf eine Vielzahl von Speicherelementen angewendet werden. Es führen also viele Instanzen den gleichen Code für unterschiedliche Daten aus. Der durch das Execution Model definierte Indexraum für Work-Items stellt gleichzeitig die Beziehung zwischen Work-Item und zu bearbeitenden Speicherelement her. OpenCL stellt dem Entwickler auf zwei Wegen ein hierarchisches datenparalleles Modell zur Verfügung. Im expliziten Fall wird die Maximalanzahl an Work-Items sowie die Aufteilung der Items in Work-Groups angegeben. Im impliziten Fall wird nur die Anzahl der Work-Items angegeben und die Aufteilung in Work-Groups übernimmt OpenCL.

13 / Lukas Abels-Vehns Seite Task Parallel Model (aufgabenparalleles Modell) Das Task Parallel Model ist vergleichbar mit der Benutzung von Threads auf einer CPU. Dabei werden verschiedene Aufgaben über eine Queue eingegeben und parallel von den verfügbaren Recheneinheiten abgearbeitet. Das aufgabenparallele Modell ist unabhängig von dem im Execution Model definierten Indexraum OpenCL Framework Das OpenCL Framework ist die Umsetzung der in der Architektur beschriebenen Modelle für die Benutzung durch den Entwickler. Durch das Framework wird es Anwendungen ermöglicht, über einen Host einen oder mehrere OpenCL Devices anzusprechen und in einem parallelen System zusammenzufassen. Im Framework sind die folgenden Komponenten zusammengefasst: OpenCL Platform Layer: Die OpenCL Plattformschicht ermöglicht der Hostanwendung das Aufsuchen von OpenCL Devices sowie die Erstellung von Kontexten zur Benutzung dieser Devices. OpenCL Runtime: Die OpenCL Runtime stellt Mittel für die Bearbeitung von erstellen Kontexten zur Verfügung OpenCL Compiler: Der OpenCL Compiler ist für die Erstellung von für die OpenCL Devices ausführbaren Programmen zuständig. Diese Programme sind die kompilierten Versionen der Kernel, die in der OpenCL C Programmiersprache geschrieben sind.

14 / Lukas Abels-Vehns Seite 14 3 Aparapi Aparapi (a parallel API) ist eine offene Bibliothek, die es Java Entwicklern ermöglicht, die Leistung ihrer GPU durch OpenCL zu nutzen. Dies wird ermöglicht, in dem zur Laufzeit der Java Bytecode in OpenCL Code übersetzt und dann auf der GPU ausgeführt wird [APARAPI]. Aparapi wurde ursprünglich von AMD entwickelt und im September 2011 als open source veröffentlicht [AMD11]. Aparapi ist für die Verwendung mit einem datenparallelen Programmiermodell entwickelt [APARAPI]. 3.1 Ausführungsmodi Aparapi kann in mehreren Modi ausgeführt werden. Der erste Modus ist der GPU Modus, bei dem die Rechenleistung des Grafikchips benutzt wird. Als einer der Alternativmodi steht der JTP (Java Thread Pool) Modus zur Verfügung, bei dem der für die GPU beabsichtigte Aparapi Code im Java Thread Pool ausgeführt wird. Dieser Modus wird automatisch aktiviert, sollte aus irgendeinem Grund die Ausführung auf der GPU fehlschlagen [APARAPI]. Zusätzlich gibt es noch den CPU Modus, bei dem, wie beim GPU Modus, versucht wird, den Kernel Code in OpenCL Code umzuwandeln und dann auf der CPU auszuführen sowie den SEQ (sequentiellen) Modus, bei dem der Code sequentiell in einer Java Schleife ausgeführt wird, ohne die Nutzung von OpenCL [APARAPI4]. 3.2 Vorraussetzungen Um Aparapi in vollem Umfang in Java Programmen nutzen zu können, müssen einige Vorraussetzungen erfüllt werden. Analog zu den allgemeinen Vorraussetzungen für die Nutzung von OpenCL, muss auch für Aparapi ein OpenCL-fähiges Betriebssystem zur Verfügung stehen. Des Weiteren benötigt Aparapi nach momentanen Stand (Dezember 2011) sowohl eine OpenCLkompatible Grafikkarte von AMD, sowie die OpenCL Treiber von AMD (AMD APP SDK v2.5 oder neuer) [APARAPI2]. Abschließend wird noch die Aparapi Bibliothek in.jar Form, sowie die plattformabhängige native Java Schnittstelle zu OpenCL in Form einer.dll (Windows) oder.so (Linux) benötigt.

15 / Lukas Abels-Vehns Seite Nutzung von Aparapi Ein simples Beispiel für die Nutzung von Aparapi ist durch die Addition der Einzelwerte von zwei float Arrays und das Speichern in einem dritten float Array gegeben. Der sequentielle Code für dieses Szenario könnte so aussehen: Dieser Code lässt sich nun durch Aparapi einfach parallelisieren: Im obigen Code wird die abstrakte Klasse Kernel in einer anonymen Klasse abgeleitet und die Methode run() überschrieben. In dieser Methode wird dann die globale ID des Work-Items, welches gleichzeitig der zu bearbeitende Index des Arrays ist, abgerufen und die Addition ausgeführt.

16 / Lukas Abels-Vehns Seite Expliziter Speichertransfer Nach jedem Aufruf von Kernel.execute(range) werden die verwendeten Speicherobjekte vom OpenCL Device wieder zum Host kopiert. Dies kann bei der Benutzung von Kernel.execute(range) in einer Schleife zu unnötigen Speichertransfers führen, die die Performance des Programms beeinträchtigen. Um dieses Problem zu lösen, besteht in Aparapi die Möglichkeit, explizite Speichertransfers vorzunehmen. Folgende Codebeispiele in Anlehnung an die offiziellen Beispiele auf der Aparapi Seite sollen diese Problematik und die Lösung verdeutlichen: Im Falle von zum Beispiel 1000 Schleifendurchläufen würden hier 999 unnötige Speichertransfers stattfinden. Diese lassen sich durch das Setzen des Kernels in den expliziten Modus und das manuelle Transferieren von Daten verhindern:

17 / Lukas Abels-Vehns Seite Schleifen mit bekannter Iterationsanzahl Manche Fälle, in denen die Verwendung von expliziten Speichertransfers sinnvoll wäre, können auf eine andere Weise in Aparapi gelöst werden. Falls der Aufruf von Kernel.execute(range) die einzige Anweisung innerhalb einer Schleife und zusätzlich die Anzahl der Schleifendurchläufe vor Beginn der ersten Iteration bekannt ist, kann die Schleife durch die Benutzung von Kernel.execute(range, iterations) ersetzt werden. Hier wird die Iterationsanzahl als zweiter Parameter angegeben, wodurch Aparapi die Erstellung Schleife übernimmt und dadurch die Anzahl der Speichertransfers minimiert. Anwendungen, bei denen der Kernel Code die Nummer der aktuellen Iteration feststellen muss, können innerhalb von Kernel.run() auf die Methode getpassid() zugreifen, um die aktuelle Iterationszahl zu bekommen. Das folgende Codebeispiel verdeutlicht dieses Szenario:

18 / Lukas Abels-Vehns Seite 18 Hier wird mit expliziten Speichertransfers gearbeitet, um im Kernel Code auf die aktuelle Iterationszahl zugreifen zu können. Dies lässt sich zu diesem Code mit Hilfe von Kernel.execute(range, iterations) vereinfachen. 3.4 Vergleich zu anderen Bibliotheken Im Vergleich zu anderen Bibliotheken, die die OpenCL API für die Java Programmiersprache verfügbar machen, wie beispielsweise JOCL, bietet Aparapi den Vorteil, dass Java-fremde Konzepte, wie das explizite Speichermanagment oder die Benutzung von OpenCL C als Programmiersprache für die Kernel, vor dem Entwickler verborgen werden. Das im vorhergehenden Abschnitt aufgeführte Beispiel zur parallelen Addition von zwei float Arrays würde

19 / Lukas Abels-Vehns Seite 19 in JOCL ungefähr 100 Zeilen Code umfassen. Dieser Unterschied ist durch den hohen Verwaltungsaufwand von OpenCL für das explizite Anlegen und Freigeben von Speicherobjekten zu erklären [JOCL]. 3.5 Beschränkungen Nicht jeder Java Code kann durch Aparapi in OpenCL Code übersetzt werden. Folgende Richtlinien sollten bei der Erstellung von Kernel in Java beachtet werden. Die hier beschriebenen Beschränkungen beziehen sich nur auf den Code innerhalb der Kernel.run() Methode und davon benutzbare Methoden Datentypen Nur die primitiven Java Datentypen boolean, byte, short, int, long und float sowie eindimensionale Arrays dieser Typen können von Aparapi benutzt werden. Die Benutzung des primitiven Typs double hängt von der benutzten Grafikkarte, den Treibern und der OpenCL- Version ab. Es wird zur Laufzeit bestimmt, ob die für die Ausführung bestimmte Plattform double unterstützt. Falls das nicht der Fall ist und der Kernel Code double verwendet, wird der Code im JTP Modus ausgeführt. Außerdem ist der Datentyp char nicht unterstützt. In einer neueren Version von Aparapi wird ebenfalls der Zugriff auf simple Objekte ermöglicht. Simple Objekte sind in diesem Zusammenhang Objekte, deren Felder primitive Datentypen sind und durch Getter und Setter erreichbar sind Felder Wenn die Felder der von Kernel abgeleiteten Klasse primitive Arrays sind, können aus dem Kernel Code heraus die Elemente dieser Arrays sowohl gelesen als auch beschrieben werden. Hierbei ist anzumerken, dass Java bei der Erstellung einer anonymen Klasse, wie im obigen Beispiel, versteckte Felder für von dieser Klasse erreichbare, mit final deklarierte, primitive Arrays erstellt und diese ebenfalls vom Kernel Code aus les- bzw. beschreibbar sind. Des Weiteren sind static final Felder vom Kernel Code aus lesbar.

20 / Lukas Abels-Vehns Seite Arrays Es werden nur eindimensionale Arrays von Aparapi unterstützt. Außerdem kann die erweiterte for- Syntax ( for (int i : arrayofint) {..} ) nicht im Kernel Code benutzt werden, da im Hintergrund eine flache Kopie des Arrays erstellt wird Methoden Referenzen auf oder durch ein Java Objekt, welches nicht die eigene Kernel Instanz ist, führen zum sofortigen Abbruch der Übersetzung des Bytecodes in OpenCL Code. Jedoch bestehen einige wenige Ausnahmen zu dieser Regel in Bezug auf den Zugriff auf Getter und Setter von Objekten in Arrays, die vom Kernel Code referenziert werden. Statische Methoden, Rekursion und Methoden Überladung werden nicht von Aparapi unterstützt. Des Weiteren gibt es in der Kernel Klasse Ersatzmethoden für den Großteil der Funktionen aus der java.lang.math Bibliothek. Diese werden bei der Ausführung auf der GPU durch die entsprechenden OpenCL-Funktionen und bei der Ausführung im JTP mit den java.lang.math Funktionen ersetzt Weitere Beschränkungen Zusätzlich zu den oben genannten Beschränkungen, gibt es in Aparapi keine Unterstützung von Exceptions, dem Schlüsselwort new zur Erstellung von Arrays oder Objekten und den Schlüsselwörtern switch, break und continue in Bezug auf Abfragen und Schleifen. Eine komplette und auf dem neuesten Stand gehaltene Liste der Beschränkungen und Richtlinien findet sich unter [APARAPI3].

21 / Lukas Abels-Vehns Seite 21 4 Anwendungsbeispiel: Aggregation von Zeitreihen Ein Bereich aus dem Umfeld der SOPTIM AG, die Energielogistik, in dem parallelisierbare Aufgaben anfallen, ist die Aggregation von Zeitreihen. Eine Zeitreihe umfasst dabei für einen Tag eine Reihe von 100 Viertelstunden-Werten, die zum einen den Stromverbrauch in Kilowattstunden, oder zum anderen den Preis pro Kilowattstunde angeben. Diese Zeitreihen werden Zählpunkten zugeordnet, die wiederum Verträgen zugeordnet sind. Die Aggregation von Zeitreihen bezeichnet das Multiplizieren der Verbrauchswerte mit den zugehörigen Preiswerten für denselben Zeitraum, um abschließend aufsummierte Werte für zum Beispiel einen Zählpunkt pro Monat oder Vertrag pro Jahr zu bekommen. Die Berechnungen der einzelnen Produkte von Verbrauchswerten und Preiswerten sind unabhängig von einander und lassen sich parallelisieren. 4.1 Testaufbau Zur Untersuchung, ob die Benutzung von Grafikkarten zur Aggregation von Zeitreihen mit Hilfe von Aparapi durchführbar ist, wurde eine Testapplikation entwickelt. Diese Applikation besteht aus einem Kernel zur Multiplikation von einem Verbrauchs- mit einem Preiswert, einer Schnittstelle zum Einlesen von Zeitreihen, die für die Zwecke des Tests aus CSV Dateien bestehen, und einem Hauptteil, der die beiden Teile zusammenfügt und organisiert. Der Ablauf der Applikation ist folgendermaßen aufgebaut: In zwei separaten Threads werden Verbrauchs- und Preiszeitreihen eingelesen und ihre Werte auf separate Streams geschrieben. Dabei beträgt die Anzahl der eingelesenen Verbrauchszeitreihen ein Vielfaches der Preiszeitreihen, da für den einen Zeitraum dieselben Preise auf verschiedene Verbräuche angewendet werden. Im Hauptteil der Anwendung werden solange Zeitreihenwerte von den Streams gelesen, bis eine einstellbare Buffergröße erfüllt ist. Anschließend wird der Kernel zur Multiplikation der Werte erstellt, die Daten auf die GPU übertragen sowie die Berechnung gestartet. Die folgenden Codeausschnitte zeigen die Stellen des Beispielprogramms, an denen Aparapi zum Einsatz kommt.

22 / Lukas Abels-Vehns Seite 22 Oben dargestellt ist die Klasse Aggregationskernel, die von der Aparapi Klasse Kernel erbt. Die beiden Methoden setpreiswertanindex und setverbrauchswertanindex werden benutzt, um die Werte Arrays zu füllen und anschließend ein Signal an den Kernelthread (siehe folgender Ausschnitt) zu geben, der dann die run() Methode ausführt, in der die Verbrauchswerte mit dem

23 / Lukas Abels-Vehns Seite 23 jeweiligen Preiswert multipliziert werden. Der Index des für jeden Verbrauchswert zugehörigen Preiswert lässt sich über den Verbrauchswert Index modulo der Anzahl der Preiswerte bestimmen. Dieser Code initialisiert einen neuen Thread, der die Ausführung des Kernels steuert. Zuerst wird solange gewartet, bis die Werte Arrays des Kernels gefüllt wurden, um anschließend in einer Schleife zehn Mal die Berechnung zu starten. Dabei werden vor und nach jedem Aufruf von kernel.execute() die Werte zur GPU gesendet und zurück geholt. Dies simuliert die Durchführung des Programms mit realen Messwerten, bei denen die Daten bei jeder Ausführung unterschiedlich wären und zur GPU transferiert werden müssten. 4.2 Testauswertung Für den Test wurden die Preiswerte für einen Monat (30 Zeitreihen) und eine variable Größe an Verbrauchszeitreihen eingelesen. Die verwendeten Zeitreihen besitzen jeweils 96 Viertelstundenwerte, insgesamt ergibt das 2880 Preiswerte und eine um den jeweils angegebenen Faktor vergrößerte Anzahl an Verbrauchswerten. Das Programm wurde sowohl im GPU, als auch im JTP Modus jeweils zehn Mal ausgeführt und die Ausführungsdauern notiert. Anschließend wurde der erste Wert aufgrund von Initialisierungsoperationen, die die Rechenzeit verschleiern, gestrichen und der Durchschnittswert der restlichen neun Ausführungszeiten ermittelt. Die verwendete Hardware ist eine AMD Phenom II

24 / Lukas Abels-Vehns Seite 24 X4 945 CPU mit einer Taktfrequenz von 4x3.00 GHz und eine ATI Radeon HD 5850 Grafikkarte. Dabei ergaben sich folgende Werte: Modus / Faktor x1000 x2000 x4000 x8000 x16000 x30000 x45000 Verbrauchswerte ( ) ( ) ( ) ( ) ( ) ( ) ( ) (Berechnungen) JTP 20,5 ms 33,2 ms 68,5 ms 193,2 ms 414,8 ms 925,8 ms 1325,9 ms GPU 5,2 ms 8,5 ms 16,1 ms 31,5 ms 64,4 ms 118,5 ms 166,8 ms Verbesserung Ausführungszeit der ~x3,9 ~x3,9 ~x4,2 ~x6,1 ~x6,4 ~x7,8 ~x7,9 Die beobachteten Werte zeigen eine deutliche Leistungssteigerung durch die Verwendung einer GPU. Der Faktor der Verkürzung der Ausführungszeit liegt zwischen circa 3,9 und 7,9. Die große Spanne zwischen den Faktoren ist durch die Speichertransferzeit zu erklären, die in den Werten für die GPU mit eingeschlossen ist. Es lässt sich daraus schließen, dass die Speichertransferzeit für geringe Datenmengen länger dauert, als die Zeit, die durch die erhöhte parallele Rechenleistung gewonnen wird. Der Graph zeigt den Verlauf der Ausführungszeiten an

25 / Lukas Abels-Vehns Seite 25 logarithmischen Skalen. Hier ist deutlich der Anstieg im Verbesserungsfaktor zu erkennen, da der Abstand zwischen den beiden Kurven zu Beginn noch ungefähr zwei Abstandseinheiten beträgt und später auf 3 Einheiten ansteigt, was bei der angegebenen Skalierung einem Faktor von circa 4 und 8 entspricht. Es ist zu erwarten, dass der dargestellte Verlauf sich nicht unendlich in dieser Form fortsetzt. Ab einem gewissen Punkt wird der Verbesserungsfaktor wieder sinken, da die parallele Rechenkraft der GPU vollständig ausgenutzt und daher Operationen auf der GPU auf die Fertigstellung von vorherigen Operationen warten müssen. Des Weiteren geht aus den gemessenen Werten hervor, dass die Initialisierungsoperationen für die Ausführung auf der GPU zusätzlich circa 565 ms in Anspruch nehmen. Zur Berechnung dieses Werts wurden die durchschnittlichen Ausführungszeiten jeweils von den nachstehenden Zeiten des ersten Durchlaufs abgezogen und anschließend der Durchschnitt dieser Werte bestimmt. Ausführungszeiten des ersten Durchlaufs: Modus / Faktor Verbrauchswerte x1000 x2000 x4000 x8000 x16000 x30000 x45000 GPU 550 ms 540 ms 573 ms 618 ms 642 ms 715 ms 771ms Zu den Initialisierungsoperationen zählt unter anderem das Kompilieren des Java Bytecodes in OpenCL C Code. Da diese Operationen nur bei der ersten Verwendung des Kernel durchgeführt werden, kann der Kernel bereits vor Starten des Einlesens der Daten kompiliert werden und anschließend, wenn Daten verfügbar sind, schneller ausgeführt werden.

26 / Lukas Abels-Vehns Seite 26 5 Zusammenfassung und Ausblick Diese Seminararbeit bietet eine Einführung in das Thema des General-purpose computing on Graphics Processing Units (GPGPU) mit Hilfe des offenen Standards OpenCL. Es wurde die Geschichte von GPGPU, sowie die Gründe für die Entwicklung eines Standards in diesem Bereich beschrieben. Des Weiteren geht die Arbeit auf die Architektur von OpenCL ein und zeigt die Verwendung dieser Technologie durch Aparapi, einer Schnittstelle zu OpenCL für Java. Außerdem wurden einige Anwendungsgebiete von GPGPU und die Stärken und Schwächen des Frameworks dargestellt. Im Anschluss an diese Arbeit kann nun eine Suche im Umfeld der SOPTIM AG nach parallelisierbaren Aufgaben, bei denen möglichst wenig Datentransfer und möglichst viele Berechnungen nötig sind, durchgeführt werden. Es ist zu erwarten, dass sich der Performancegewinn durch den Einsatz von GPGPU, wie im Anwendungsbeispiel gezeigt, noch verbessern lässt. Dazu wäre es denkbar, Kompressionsverfahren auf die Daten anzuwenden, damit die Datentransferzeit zwischen Hauptspeicher und GPU noch verkürzt und stattdessen die überschüssige, parallele Rechenkraft zur Dekompression genutzt wird.

27 / Lukas Abels-Vehns Seite 27 6 Literaturverzeichnis [TOP500] Zuletzt abgerufen am: [GARKIRK10] M. Garland und D. B. Kirk. Understanding Throughput Oriented Architectures, veröffentlicht im Magazin Communications of the ACM, Ausgabe 11, November DOI: / URL: Zuletzt abgerufen am: [KHRONOS] Zuletzt abgerufen am: [APPLE09] Zuletzt abgerufen am: [APARAPI] Zuletzt abgerufen am: [APARAPI2] Zuletzt abgerufen am: [APARAPI3] Zuletzt abgerufen am: [APARAPI4] Zuletzt abgerufen am: [AMD10] Zuletzt abgerufen am: [AMD11] Zuletzt abgerufen am: [OPENCL] Zuletzt abgerufen am: [JOCL] Zuletzt abgerufen am: [NVIDIA11] d= Zuletzt abgerufen am:

28 / Lukas Abels-Vehns Seite 28 7 Abbildungsverzeichnis 2.1: Schematischer Vergleich der Architektur einer CPU und GPU Quelle: Zuletzt abgerufen am: : Plattform Modell aus der OpenCL Spezifikation Quelle: Seite 20 Zuletzt abgerufen am: : OpenCL Memory Model Quelle: Zuletzt abgerufen am: