Aachen, 17.01.2012 Seminarvortrag Von: Lukas Abels-Vehns OpenCL mit Aparapi.

Präsentation zum Thema: "Aachen, 17.01.2012 Seminarvortrag Von: Lukas Abels-Vehns OpenCL mit Aparapi."—  Präsentation transkript:

1 Aachen, 17.01.2012 Seminarvortrag Von: Lukas Abels-Vehns OpenCL mit Aparapi

2 Folie 2 GPGPU (General-purpose computing on Graphics Processing Units) OpenCL Aparapi Anwendungsbeispiel Zusammenfassung und Ausblick Inhalt

3 Folie 3 Entwicklung der Computerspieleindustrie brachte die Hersteller von Grafikkarten dazu, immer leistungsfähigere Grafikchips herzustellen Potenzial an Rechenleistung wurde aber nur in Grafikanwendungen benutzt Software aus anderen Bereichen (z.B. wissenschaftliche Anwendungen) hat großen Bedarf an paralleler Rechenleistung NVIDIA schuf 2006 CUDA, die erste Programmierplattform zur Benutzung von Grafikchips für nicht-graphische Zwecke (GPGPU) Einsatzgebiete von GPGPU sind zum Beispiel Wissenschaft, Ingenieuerswesen und Architektur Durch GPGPU zum Beispiel hohe Leistung bei numerischen Berechnungen und Performancegewinne bei physikalischen Simulationen GPGPU (General-purpose computing on Graphics Processing Units)

4 Folie 4 GPGPU Große parallele Rechenleistung einer GPU ergibt sich aus der Architektur GPU besitzen im Vergleich zu modernen CPU ein Vielfaches an Recheneinheiten CPU Großer Cache Großer Befehlssatz Wenige ALU (Arithmetisch Logische Einheit) GPU Kleiner Cache Kleiner Befehlssatz Viele ALU

5 Folie 5 OpenCL - Allgemeines OpenCL steht für Open Computing Language und ist ein offener Standard für plattformunabhängiges, verteiltes Rechnen Ursprünglich von Apple entwickelt, zusammen mit Firmen wie AMD, NVIDIA, Intel und IBM zu einer ersten Version ausgearbeitet Fortlaufende Entwicklung steht unter der Leitung der Khronos Group, einer Industrievereinigung von über 100 Konzernen OpenCL Programme, sogenannte Kernel, werden in OpenCL C geschrieben OpenCL C basiert auf der standardisierten Sprache C, besitzt jedoch einige Einschränkungen (z.B. keine Pointer auf Funktionen, keine Rekursion, keine Arrays variabler Länge) Für die Nutzung von OpenCL müssen einige Vorraussetzungen erfüllt werden  Implementierung im Betriebssystem (erstes OpenCL kompatible OS war Mac OS X 10.6, heute auch Windows und einige Linux-Distributionen)  OpenCL kompatible Hardware (der Großteil der verfügbaren GPUs und CPUs)  OpenCL Treiber für die jeweilige Hardware

6 Folie 6 OpenCL - Architektur Die OpenCL Architektur teilt sich in vier Modelle auf Platform Model Execution Model Memory Model Programming Model Wichtige Begriffe sind: Host: Gerät, auf dem die Host-Applikation läuft und das Befehle an die OpenCL-fähigen Geräte (Devices) sendet Device: OpenCL-fähiges Gerät, welches aus einer oder mehreren Compute Units besteht Compute Unit: Eine Compute Unit ist unterteilt in mehrere Processing Elements, die die Berechnungen ausführen Kernel: Das Programm, welches auf dem OpenCL Device ausgeführt wird. Quellcode des Kernel liegt der Host-Applikation bei, muss auf dem Device kompiliert werden. Command Queues: Befehlswarteschlangen werden für die Übertragung von Befehlen an die OpenCL Devices benutzt. Befehle umfassen die Ausführung eines Kernel, den Transfer von Speicherobjekten oder die Synchronisation von Abläufen Context: Wird von der Host Applikation definiert und umfasst die verfügbaren Devices, die auszuführenden Kernel als Quellcode sowie in kompilierter Form und Memory Objects, die den vom Host und den Devices bearbeitbaren Speicher darstellen

7 Folie 7 OpenCL – Plattform Model Das Platform Model umschreibt die Beziehungen zwischen dem Host und den verbundenen Devices, sowie die darin enthaltenen Compute Units und Processing Elements Host steuert den Ablauf der Anwendung Datentransfergeschwindigkeit zwischen Host und Device ist langsamer als interne Geschwindigkeit des Device Daher ausreichend Daten auf den Device transferieren, um Processing Elements möglichst effektiv auszulasten

8 Folie 8 OpenCL – Execution Model Das Execution Model beschreibt die zwei Teile der Ausführung eines OpenCL Programms 1.Die Host Applikation, die auf dem Host Gerät ausgeführt wird 2.Die Kernel, die auf den Devices ausgeführt werden Host Applikation organisiert die Ausführung der Kernel über die Befehlswarteschlange Bei Übertragung eines Kernel zum Device wird ein Indexraum angelegt Indexraum ist ein N-Dimensionaler Raum (N entweder 1,2 oder 3), ID eines Punktes ist ein N-Dimensionales Tupel Jeder Punkt des Indexraum hat ein Work-Item (eine Instanz des auszuführenden Kernels) Work-Item ist durch den Punkt im Indexraum, die globale ID, identifizierbar Work-Items führen den gleichen Code aus, jedoch unterscheidet sich der spezifische Ablauf des Codes und die zu bearbeitenden Daten je nach Item Work-Groups umfassen zusätzlich mehrere Work-Items

9 Folie 9 OpenCL – Memory Model Im Memory Model sind die vier unterschiedlichen Speicherregionen beschrieben 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.

10 Folie 10 OpenCL – Programming Model Das OpenCL Programming Model beschreibt zwei Vorgehensweisen: 1. Data Parallel Model Beim Data Parallel Model wird über viele Instanzen der gleiche Code für unterschiedliche Daten ausgeführt Der im Execution Model definierte Indexraum stellt die Beziehung zwischen Work-Item und zu bearbeitenden Daten her Der Entwickler gibt die Maximalanzahl der Work-Items an und kann optional im expliziten Fall die Aufteilung in Work-Groups angeben 2. Task Parallel Model Das Task Parallel Model ist vergleichbar mit der Benutzung von Threads auf einer CPU Es werden verschiedene Aufgaben über eine Queue eingegeben und parallel von den verfügbaren Recheneinheiten ausgeführt Dieses Modell ist unabhängig vom Indexraum des Execution Model

11 Folie 11 Aparapi - Allgemeines Aparapi steht für A Parallel API und ist eine offene Bibliothek zur einfachen Nutzung von OpenCL in Java Entsprechender Java Bytecode wird zur Laufzeit in OpenCL Code übersetzt und auf dem OpenCL Device ausgeführt Ursprüngliche Entwicklung durch AMD, Veröffentlichung als open source im September 2011 Aparapi besitzt verschiedene Ausführungsmodi: GPU: Der beabsichtigte Code wird in OpenCL Code übersetzt und auf der GPU ausgeführt JTP: Der Code wird im Java Thread Pool anstatt auf der GPU ausgeführt. CPU: Der Code wird in OpenCL Code übersetzt und auf der CPU ausgeführt SEQ: Der Code wird in einer sequentiellen Schleife ausgeführt Falls es bei der Übersetzung in OpenCL Code zu Fehlern kommt, wird der JTP Modus aktiviert Bibliothek liegt als.jar vor, zur Benutzung von OpenCL im GPU oder CPU Modus wird noch die plattformabhängige, native Java Schnittstelle zu OpenCL benötigt Zusätzlich wird nach momentanem Stand für die OpenCL Modi eine OpenCL- kompatible Grafikkarte von AMD und die AMD OpenCL Treiber (APP SDK) benötigt

12 Folie 12 Aparapi - Codebeispiel Beispiel: Addition der Einzelwerte von zwei Arrays und Speichern in einem dritten Array Sequentieller Code: Parallelisierung durch Aparapi:

13 Folie 13 Aparapi – Expliziter Speichertransfer Nach jedem Aufruf von Kernel.execute(range) werden die verwendeten Speicherobjekte vom OpenCL Device wieder zum Host geschickt Im Beispiel würden bei 1000 Schleifendurchläufen 999 unnötige Speichertransfers stattfinden

14 Folie 14 Aparapi – Expliziter Speichertransfer In Aparapi kann der Kernel in den expliziten Modus gesetzt werden, um unnötige Speichertransfers zu verhindern Der Entwickler bestimmt dadurch, wann welche Daten vom Host zum Device und wieder zurück transferiert werden

15 Folie 15 Aparapi – vereinfachte Schleifen In einer Schleife wird nur Kernel.execute(range) ausgeführt und die Anzahl der Schleifendurchläufe steht vorher fest Verwendung von explizitem Speichertransfer würde Sinn machen, lässt sich jedoch auf andere Weise lösen

16 Folie 16 Aparapi – vereinfachte Schleifen Eine solche Schleife kann durch Kernel.execute(range, iterations) ersetzt werden Dabei übernimmt Aparapi die Erstellung der Schleife und optimiert die Anzahl der Speichertransfers Innerhalb des Kernel Code kann über getPassId() auf die Nummer der aktuellen Iteration zugegriffen werden

17 Folie 17 Aparapi – Vergleich und Beschränkungen Stärken von Aparapi: Einfache Benutzbarkeit durch vertraute Java Syntax Kein Zwang, explizites Speichermanagement zu benutzen Kernel werden nicht in OpenCL C geschrieben Andere Bibliotheken für OpenCL in Java ähneln stark der Vorgehensweise von C++ Dadurch viel Code für die Verwaltung von OpenCL Objekten und Speichermanagement Für die erfolgreiche Umwandlung des Java Kernel Code in OpenCL Code durch Aparapi müssen einige Richtlinien eingehalten werden, unter anderen: Nur primitive Datentypen (boolean, byte, float, int, usw.) und einfache Objekte, deren Felder primitive Datentypen sind, sind erlaubt Nur eindimensionale Arrays Referenzen auf oder durch Objekte, die nicht die Kernel Instanz sind, führen zum Abbruch der Code Übersetzung

18 Folie 18 Anwendungsbeispiel Suche nach parallelisierbaren Aufgaben in der Energielogistik, dem Umfeld der SOPTIM AG Ergebnis: Aggregation von Zeitreihen Zeitreihe: Reihe von Werten für jede Viertelstunde eines Tages Stellen Stromverbräuche oder Strompreise dar Multiplizieren von Verbrauchswerten mit den dazugehörigen Preiswerten und die anschließende Aufsummierung der Einzelwerte für einen bestimmten Zeitraum Berechnung der einzelnen Produkte von Verbrauchs- und Preiswert sind unabhängig von einander und lassen sich parallelisieren Entwicklung einer Testapplikation zur Überprüfung, ob sich die Aggregation von Zeitreihen mit Aparapi effektiv umsetzen lässt Ablauf: Es werden Zeitreihen aus.csv Dateien eingelesen und auf Streams geschrieben Werte werden von den Streams gelesen bis eine einstellbare Buffergröße erreicht wird Ein Kernel wird zur Multiplikation der Werte erstellt und die Berechung auf einer GPU durchgeführt

19 Folie 19 Anwendungsbeispiel Testapplikation im GPU und JTP Modus jeweils 10 Mal ausgeführt Preiswerte für einen Monat (2880 Werte) und jeweils um den angegebenen Faktor vergrößerte Anzahl Verbrauchswerten Erster Durchlauf aufgrund von Initialisierungsoperationen gestrichen, Durchschnitt der restlichen 9 Läufe ermittelt Verwendete Hardware: CPU: AMD Phenom II X4 945 (4x3.00 GHz) GPU: ATI Radeon HD 5850

20 Folie 20 Anwendungsbeispiel

21 Folie 21 Anwendungsbeispiel Beobachtete Werte zeigen deutliche Leistungssteigerung durch Verwendung einer GPU Faktor der Verkürzung der Ausführungszeit liegt zwischen ca. 3,9 und 7,9 Dieser Unterschied lässt sich durch die Speichertransferzeit erklären Transferzeit für geringe Datenmengen dauert länger, als die gewonnene Zeit durch die parallele Rechenkraft Dargestellter Verlauf wird sich nicht unendlich so fortsetzen Verbesserungsfaktor wird wieder sinken, da die Rechenkraft der GPU ausgeschöpft ist und Operationen auf die Fertigstellung von vorherigen Operationen warten müssen Gemessene Werte zeigen, dass Initialisierungsoperationen durchschnittlich 565 ms in Anspruch nehmen Ausführungszeiten der ersten Durchläufe: Zu Initialisierungsoperationen zählt zum Beispiel die Übersetzung des Java Bytecode in OpenCL C Code Da diese Operationen nur einmal durchgeführt werden müssen, kann zum Beispiel schon zu Beginn des Programms, während des Einlesens der Daten, der Kernel einmal gestartet werden, um ihn zu kompilieren

22 Folie 22 Zusammenfassung und Ausblick Einführung in das Thema GPGPU (General-purpose computing on Graphics Processing Units) Wichtige Punkte des offenen Standards OpenCL wurden behandelt Verwendung von OpenCL durch Java Schnittstelle Aparapi ausführlich erklärt Nutzen von OpenCL und Aparapi anhand eines Anwendungsbeispiels veranschaulicht Im Anschluss kann nach weiteren, parallelisierbaren Aufgaben im Umfeld der SOPTIM AG gesucht werden Anforderungen: Möglichst geringer Datentransfer Möglichst viele Berechnungen Performancegewinn der GPU lässt sich eventuell noch durch Verwendung von Kompressionsverfahren verbessern

23 Folie 23 Vielen Dank für Ihre Aufmerksamkeit