Bachelorarbeit:
Performance-Analyse der SkelCL-Bibliothek am Beispiel von diskreter Kosinustransformation und Histogrammerstellung
Thema
Gegenüber der Programmierung von sequentiellen Systemen gibt es bei der Programmierung für parallele Systeme neue Schwierigkeiten; insbesondere müssen Algorithmen angepasst werden, um parallel ausführbar zu sein, damit das Programm überhaupt von den Vorteilen eines parallelen Systems profitieren kann. Bei der Programmierung für GPUs (mit APIs wie OpenCL oder CUDA) sind die Unterschiede gegenüber traditionellen sequentiellen Programmen noch stärker ausgeprägt. Durch die speziellen Anforderungen von Echtzeit-3D-Grafikberechnungen haben sich GPUs zu hochparallelen Systemen mit sehr vielen simplen Kernen entwickelt. Diese Eigenheiten von GPU-Architekturen erfordern spezielle parallele Programmiermodelle für GPUs, die sich von sequentiellen Modellen und auch anderen parallelen Programmiermodellen für Multi-Core-CPUs (die vergleichsweise wenige, dafür komplexere und mächtigere Kerne haben) stark unterscheiden.
OpenCL wurde als geräteunabhängige Low-Level-API primär zur Programmierung von GPUs entworfen und orientiert sich daher vorrangig an den Architektur-Eigenheiten von GPUs. Ins- besondere existiert in OpenCL eine Trennung zwischen dem Host-Programm, das auf der CPU des Systems läuft und dem sogenannten Kernel, der mit der OpenCL-API auf das OpenCL-Gerät übertragen und dort ausgeführt wird. Diese Unterteilung des Programms in mehrere, in verschiedenen Programmiersprachen implementierte Teile erhöht die Komplexität von OpenCL-Programmen. Diese Trennung betrifft auch die Speicherverwaltung in OpenCL-Programmen; Daten müssen explizit vom Hauptspeicher des Systems in den Gerätespeicher und zurück kopiert werden.
Eine weitere Schwierigkeit ist das Fehlen einer transparenten, automatischen Speicherhierarchie in gängigen GPU-Architekturen. Da OpenCL primär für die GPU-Programmierung entwickelt wurde, greift es diese Einschränkung auf und stellt Kerneln verschiedene Arten von Speicher zur Verfügung (globaler Speicher, lokaler Speicher, privater Speicher), die verschiedene Performance-Eigenschaften aufweisen. Für ein effizientes OpenCL-Programm ist es deshalb erforderlich, diese Speicherbereiche gezielt einzusetzen, um die bestmögliche Performance zu erzielen.
Insgesamt macht die Low-Level-Natur es schwierig, effiziente OpenCL-Programme zu entwickeln. Durch das sich sehr stark an der Architektur von GPUs orientierende Design ist es natürlich einerseits möglich, die Hardware optimal auszunutzen, aber das erfordert eine gute Kenntnis der Details von GPU-Architekturen, die sich zudem deutlich von traditionellen CPU-Architekturen unterscheiden.
Die SkelCL-Bibliothek setzt hier an und soll es ermöglichen, effiziente Programme für GPUs einfacher und mit weniger Aufwand zu entwickeln, als es direkt mit OpenCL möglich ist. SkelCL implementiert sogenannte Skelette – gängige Grundmuster vieler paralleler Algorithmen wie zum Beispiel ’map’ oder ’reduce’ – auf Basis von OpenCL. Außerdem bietet SkelCL Containerklassen für die Verwendung mit diesen Skeletten, die die Speicherverwaltung im Programm vereinfachen, indem sie die Daten automatisch zwischen dem Hauptspeicher und dem Gerätespeicher kopieren. Schließlich bietet die SkelCL-Skelette auch transparente Unterstützung zur Nutzung mehrerer OpenCL-Geräte gleichzeitig (wie zum Beispiel Multi-GPU- Systeme); in normalen OpenCL-Programmen müsste dies vom Programmierer vollständig selbst implementiert werden, was mit nicht unerheblichen Aufwand verbunden ist, da Synchronisierung der Geräte und das Kopieren von Daten explizit geregelt werden muss.
Natürlich muss sich bei allen Vorteilen, die SkelCL verspricht, auch die Frage stellen, in- wieweit der höhere Abstraktionsgrad und die vereinfachte Entwicklung zu Lasten der Performance gehen. Zwar kann unter vielen Bedingungen eine erhöhte Entwickerproduktivität leichte Einbußen in der Performance ausgleichen; nichtsdestotrotz ist es wichtig, dass durch die Benutzung von SkelCL die Ausführungsgeschwindigkeit eines Programms im Vergleich zu einer optimierten OpenCL-Implementierung nicht zu stark leidet.
Daher ist das Ziel dieser Arbeit, die Performance der SkelCL-Bibliothek für ausgewählte Anwendungen experimentell mit optimierten OpenCL-Implementierungen dieser Anwendungen zu vergleichen. Dazu werden zwei existierende OpenCL-Beispielprogramme ausgewählt und auf SkelCL portiert werden. Durch vergleichende Benchmarks der Implementierungen kann so die Performance von SkelCL im Vergleich zu Programmen, die direkt OpenCL verwenden, abgeschätzt werden. Diese Anwendungen werden dazu auf SkelCL portiert:
- Discrete Cosine Transform aus dem AMD APP SDK, ein Algorithmus, der vielfach in Formaten zur Komprimierung von Audio- und Bilddaten verwendet wird, beispielsweise im JPEG-Format.
- Histogram aus der Parboil-Benchmark-Suite, das ein Sättigungshistogramm für eine 2D-Grafik berechnet.
Bei diesen Anwendungen handelt es sich um bekannte Algorithmen, implementiert als Beispielprogramme und OpenCL-Benchmarks von AMD bzw. einer Forschungsgruppe der University of Illinois; es ist daher davon auszugehen, das diese Programme gut optimiert sind und so einen realistischen Vergleichspunkt für SkelCL darstellen.
Um dieses Ziel zu erreichen, werden zuerst diese Anwendungen auf die SkelCL-Bibliothek portiert; um die Vergleichbarkeit der Benchmarkergebnisse zu gewährleisten, werden keine Änderungen an den Algorithmen oder Parametern vorgenommen, die die Laufzeit beeinflussen könnten. Daraufhin werden Benchmarkergebnisse für die beiden Implementierungen der Anwendungen gesammelt; hierbei soll die gesamte Laufzeit der Programme gemessen werden, um die Performance von SkelCL zu betrachten, einschließlich von eventuellem zusätzlichem Initialisierungs-Overhead. Die Benchmarkergebnisse werden schließlich (schriftlich und in Graphen) ausgewertet und detailliert analysiert.
Literatur
Webseite von SkelCL[en]
Webseite von OpenCL [en
AMD APP SDK [en
Parboil-Benchmark-Suite [en]
Voraussetzungen
Kenntnisse in der Programmierung mit C/C++.
Kenntnisse in der Programmierung mit OpenCL (z.B. durch Besuch der Veranstaltung: "Multi-core und GPU: Parallele Programmierung")
Umfang
Bachelorarbeit (6 Wochen Bearbeitungszeit).
Student
Felix Krull