Stream Processing und High-Level GPGPU Sprachen

Transkript

1 Seminar: Programmierung von Grafikkarten Stream Processing und High-Level GPGPU Sprachen Jens Breitbart Abstract Die Leistung aktueller Prozessoren erhöht sich sehr viel schneller als dies bei Speicher der Fall ist. Um dieser Problematik entgegenzuarbeiten, werden neue Paradigmen entwickelt. Diese Ausarbeitung gibt eine Einführung in das Stream Processing Paradigma und legt die Vorteile des Ansatzes dar. Zusätzlich wird betrachtet, welche Anforderungen an die Hardware- Architekturen durch Stream Processing entstehen und in wie weit aktuelle GPUs diese erfüllen. Der zweite Teil der Ausarbeitung gibt einen Überblick über den aktuellen Entwicklungsstand von High-Level Sprachen für GPGPU Anwendungen sowie eine abschließende Bewertung. 1. Einführung Stream Processing Was ist Stream Processing? Vorteile von Stream Processing Kommunikation Berechnung Hardware-Architekturen GPUs High-Level GPGPU Sprachen Glift Brook for GPUs Accelerator PyGPU Sh Fazit Zusammenfassung Literaturverzeichnis...7

2 1. Einführung Aktuelle Prozessoren bestehen aus Millionen von Transistoren. Gordon Moore [8] analysierte bereits im Jahr 1965, dass die Anzahl der Transistoren, welche auf einem einzigen Prozessorkern untergebracht werden können, sich ungefähr alle zwei Jahre verdoppelt. Allerdings nimmt nicht nur die Anzahl dieser Transistoren zu, sondern auch ihre Taktfrequenz. Diese beiden Faktoren führen zu einem Anstieg von ca. 71% mehr Rechenleistung pro Jahr [9]. Im Gegensatz dazu erhöht sich die Leistung des Speichers relativ langsam. Die Bandbreite verbessert sich pro Jahr nur um ca. 25%, die Zugriffszeit sogar nur um 5% pro Jahr. Eine Konsequenz aus diesen Zahlen ist die immer größer werdende Lücke zwischen der verfügbaren Rechenleistung und der zur Verfügung stehenden Speicherbandbreite bzw. Speicherzugriffszeit. Eine Möglichkeit, die Rechenleistung weiterhin gut ausnutzen zu können, stellt das in den folgenden Abschnitten vorgestellte Stream Processing Paradigma dar [9]. 2. Stream Processing Das Konzept des Stream Processing existiert bereits seit 1960, wenn auch damals noch nicht unter dieser Bezeichnung. Eine frühe Art des Stream Processing findet man z.b. in Datenflussdiagrammen, welche über viele Jahre hinweg ein aktives Forschungsgebiet waren [10]. Das im folgendem vorgestellte Modell mit den entsprechenden Vorteilen wurde von John Owens in [9] vorgestellt Was ist Stream Processing? Stream Processing unterscheidet zwischen zwei grundsätzlichen Elementen: Streams und Kerneln. Ein Stream ist eine geordnete Menge an Daten, welche alle vom selben Typ sein müssen, aber nicht zwingend ein primitiver Datentyp. Zusätzlich sind auch die erlaubten Operationen auf einem Stream stark beschränkt. So ist es erlaubt, einen Stream zu kopieren, einen Stream in mehrere Substreams aufzuteilen, mit Hilfe eines Index-Streams einen Stream zu indizieren und Berechnungen auf dem Stream mit Hilfe eines Kernels durchzuführen. Ein Stream ist am besten vergleichbar mit einem Array bei der normalen Programmierung, der die genannten Anforderungen erfüllen muß. Kernel dagegen sind das Äquivalent zu Funktionen. Sie verarbeiten mehrere Streams als Eingabe und erzeugen wiederum mehrere Streams als Ausgabe. Das besondere eines Kernels ist, dass die Ausgabe nur von der Eingabe abhängt und keine Abhängigkeiten zwischen den einzelnen Elementen der Ausgabestreams existieren dürfen. In der Praxis wird von diesen strikten Anforderungen zum Teil abgewichen. Graphic Processing Units (GPUs) ermöglichen z.b. Eingaben nicht nur als Streams sondern können auch zusätzlich aus Texturen lesen. 2

3 2.2. Vorteile von Stream Processing Durch diese recht starken Einschränkungen bezüglich der zulässigen Berechnungen (Kernel) und Datenstrukturen (Streams) ist es schwer, zur Compilezeit nicht bekannte und organisierbare Berechnungen mit Hilfe des Stream Processing Paradigmas auszudrücken. Mögliche Berechnungen bieten allerdings ein hohes Optimierungspotential, insbesondere im Bereich der Kommunikation und Berechnung Kommunikation Bei der Kommunikation wird grundsätzlich zwischen zwei Arten unterschieden. Zum einem die so genannte off-chip- und zum anderen die on-chip-kommunikation. Erstere bezeichnet die Kommunikation zwischen dem Prozessor und einem externen Partner, z.b. RAM-Speicher. Onchip-Kommunikation dagegen ist die Kommunikation innerhalb eines Prozessors. Stream Processing bietet die Möglichkeit, die Kosten für off-chip-kommunikation zu reduzieren bzw. teilweise off-chip- durch on-chip-kommunikation zu ersetzen. Kernel arbeiten normalerweise auf sehr großen Streams, d.h. es müssen viele Daten von einem externen Speicher zu dem Prozessor übertragen werden. Der Vorteil bei der Übertragung sehr großer Datenmengen besteht darin, dass die relativen Kosten für die Initialisierung der Speicherbewegung im Vergleich zur Übertragung geringer sind. Bei der Übertragung eines Streams ist die Bandbreite wichtiger als die Zugriffszeit, weil diese effektiv nur bei der Initialisierung der Speicherbewegung zum Tragen kommt. In nicht streamorientierten Anwendungen ist es üblich, dass fertig berechnete Daten nicht unbedingt sofort wieder verwendet und daher zumindest in den Cache geschrieben werden müssen. Stream Processing bietet hier einen deutlichen Vorteil. Im Normalfall wendet man auf einen Stream nicht nur einen Kernel an, sondern man benutzt die Ausgaben des ersten Kernels als Eingaben für einen zweiten Kernel. In einem solchem Fall ist es nicht mehr nötig, die Daten erst in den Cache zu kopieren. Diese können vielmehr direkt vom ersten Kernel zum Zweiten übertragen werden. Das Stream Processsing Paradigma bietet einen weiteren Vorteil. Unter der Bedingung, dass Cacheverfahren eingesetzt werden, ist es möglich, die Berechnung eines Elementes zu unterbrechen und zwischenzuspeichern, sollten nicht alle für die Berechnung benötigten Daten vorhanden sein. In diesem Fall können so lange andere Elemente berechnet werden, bis die fehlenden Daten vorhanden sind Berechnung Wie bereits erwähnt, entstehen durch Stream Processing nicht nur Vorteile im Bereich der Kommunikation, sondern auch bei der Berechnung der Daten. Letztere resultieren aus den starken Beschränkungen, denen sowohl Streams als auch Kernel unterworfen sind. Ein Kernel verlangt, dass die Berechnung eines Elementes von den Berechnungen der anderen Elemente im Stream unabhängig sein muss. Jedes einzelne Element eines Streams kann also theoretisch gleichzeitig bearbeitet werden. Diese Datenparallelität ermöglicht einen linearen Speedup in Abhängigkeit von der Anzahl der Recheneinheiten, die gleichzeitig Berechnungen ausführen können. 3

4 Weiterhin ermöglicht die Forderung nach Unabhängigkeit der Berechnung eines Elementes im Kernel, dass mehrere Kernel gleichzeitig ausgeführt werden können. Unter der Bedingung, dass die Ausgaben eines Kernels als Eingaben für einen weiteren Kernel verwendet werden, kann der zweite Kernel bereits mit Berechnungen beginnen, sobald der erste Kernel Elemente in den Ausgabestream schreibt. Solche Taskparallelität ist besonders effizient, wenn für jeden einzelnen Kernel dedizierte Hardware zur Verfügung steht. Zusätzlich zu diesen beiden Eigenschaften bieten Kernel häufig die Möglichkeit, einzelne Befehle innerhalb eines Kernels parallel auszuführen. Natürlich können auch innerhalb eines Kernels nicht gleichzeitig zwei Ergebnisse in dieselbe Speicherzelle geschrieben werden. Wie allerdings in Abschnitt 2.1. beschrieben, erhalten Kernel häufig mehrere Streams als Eingabe und können somit unterschiedliche Berechnungen auf den verschiedenen Streams gleichzeitig durchführen Hardware-Architekturen Die Vorteile von Stream Processing sind auf nicht angepassten Architekturen allerdings nur theoretischer Art. Zum Beispiel kann aus der vorhandenen Datenparallelität kein Vorteil entstehen, wenn keine Recheneinheiten vorhanden sind, die gleichzeitig rechnen können. Der folgende Abschnitt wird sich auf aktuelle, für Stream Processing gut geeignete GPUs konzentrieren. Daneben existieren allerdings auch andere Architekturen wie z.b. die Cell Broadband Engine von IBM, Sony und Toshiba [4]. Abbildung 1: Grafikpipeline einer GPU [9] GPUs GPUs sind, wenn auch nicht direkt dafür entworfen, sehr gut für Stream Processing geeignet. Die Pipeline einer GPU kann, wie in Abbildung 1 gezeigt, als eine Folge von Kernel betrachtet werden, zwischen denen Streams unterschiedlicher Daten fließen. So erhält z.b. das Fragment Program als Eingabestream die vom Rasterizer erzeugten Fragmente, führt Berechnungen auf diesen aus und liefert als Ausgabe einen Stream bearbeiteter Fragmente. Diese Darstellung ist eine Vereinfachung der Architektur einer GPU, zeigt aber grundsätzlich alle für GPGPU-Anwendungen nützlichen Elemente. Eine GPU erfüllt alle Anforderungen die in Abschnitt an eine Architektur gestellt wurden. Sie enthält z.b. mehrere Fragment-Einheiten, welche Elemente in dem Fragment Program gleichzeitig berechnen können. Zusätzlich sind auch die Fragment-Einheiten unabhängig von den Einheiten für die anderen Berechnungen, so dass gleichzeitig mehrere Kernel aktiv sein können. 4

5 Zusätzlich bieten viele GPUs auch die Möglichkeit, mehrere Instruktionen in einem Takt auszuführen, z.b. ATIs R580-Architektur [1]. Zudem benutzen die Fragment- und Vertex-Einheiten sogenannte Vektor-ALUs (arithmetisch-logische Einheiten) welche meistens 4 Fließkommawerte gleichzeitig berechnen können. Im Widerspruch zu der im Abschnitt 2.1 vorgestellten Theorie weisen GPUs in bestimmten Bereichen abweichende Eigenschaften auf. So ermöglichen sie z.b. keinen indizierten Zugriff auf bestimmte Elemente im Eingabestream. Im Gegenzug bieten sie allerdings den Vorteil, innerhalb eines Vertex- oder Fragment-Programs entweder schreibend oder lesend auf Texturen zugreifen zu können. 3. High-Level GPGPU Sprachen GPUs sind ursprünglich entworfen worden, um 3D-Grafik auf dem Bildschirm darzustellen. Da dies für viele Jahre auch die einzige Anwendung von GPUs war, wurden alle APIs und Programmiersprachen daraufhin ausgelegt. Mit diesen Systemen ist es möglich, Stream Processing auf Grafikkarten zu nutzen. Allerdings ist dies wesentlich komplizierter als bei speziell dafür angepassten Systemen. Das Entwickeln eines solchen Systems ist aktuell ein sehr aktives Forschungsgebiet, in dem viele verschiedene Ansätze existieren. Einige werden im Folgenden vorgestellt Glift Glift, entwickelt u.a. von Aaron E. Lefohn [5], ist eine Bibliothek mit dem Ziel, Entwicklern das Entwerfen von Algorithmen und Datenstrukturen entkoppelt voneinander zu ermöglichen. In der Programmierung für CPUs ist dies bereits seit vielen Jahren durch Bibliotheken wie z.b. STL für C++ möglich. In den meisten aktuell existierenden Implementierungen von GPGPU Anwendungen sind Datenstrukturen und Algorithmen sehr eng miteinander verbunden. Dies führt allerdings dazu, dass solche Software schwer zu warten ist und häufig wiederkehrende Aufgaben für jede Datenstruktur wiederholt werden müssen. So bietet Glift z.b. Iteratoren an, welche unterschiedliche Arten von Adressübersetzungen durchführen können. Dies ist für Datenstrukturen auf GPUs in so fern wichtig, als dass Texturen im Grafikkartenspeicher normalerweise 2-dimensional sind, die Datenstrukturen aber häufig nicht. Glift unterstützt aktuell C++ und C for Graphics (Cg). Eine Implementierung von Glift ist zur Zeit nicht verfügbar Brook for GPUs Brook ist eine an der Stanford University entwickelte Sprache, welche das Stream Processing Paradigma umsetzt. Brook erweitert den ANSI C-Standard um Sprachkonstrukte, die es ermöglichen, Kernel und Streams direkt in C anzugeben [2]. Brook for GPUs (BrookGPU) ist eine Brook-Implementierung, welche DirectX bzw. OpenGL verwendet, um Berechnungen auf GPUs durchführen zu können. Um dies zu ermöglichen, werden in BrookGPU ein eigener Compiler und ein eigenes Laufzeitsystem verwendet. Das Laufzeitsystem wird allerdings nicht nur für den eigentlichen Ablauf des Programms benötigt sondern schützt den Entwickler auch vor Hardwarelimitationen der jeweiligen GPU [3]. Allerdings scheint BrookGPU in den letzten Jahren kaum noch aktiv entwickelt zu werden. 5

6 3.3. Accelerator Accelerator ist eine von Microsoft Research entwickelte Bibliothek, welche es dem Entwickler ermöglicht, die aus dem Stream Processing bekannte Datenparallelität zu nutzen. Die Bibliothek stellt spezielle Datenstrukturen und Funktionen zur Verfügung, die dann auf die GPU übertragen werden. Dies geschieht, indem die Datenstrukturen in eine Textur geschrieben und die Funktionen als Fragment-Shader implementiert werden. Das System benutzt die.net-laufzeitumgebung, um Fragment-Shader zu erstellen. Eine Implementierung von Accelerator ist zur Zeit nicht öffentlich verfügbar [11] PyGPU An der Lund University (Schweden) wird aktuell eine Python-Erweiterung namens PyGPU entwickelt. Das Hauptziel von PyGPU ist es, aufwendige Bildbearbeitung auf GPUs berechnen zu lassen. Zusätzlich zu den speziell für diesen Zweck implementierten Funktionen bietet es auch mathematische Funktionen, die GPGPU Berechnungen ermöglichen. Die aktuell verfügbare Version 0.1 benutzt Cg bzw. PyCg als Backend [6] Sh Sh ist eine Programmiersprache und API zum Programmieren von GPUs. Entstanden ist Sh ursprünglich als Bestandteil eines größeren Projektes namens SMASH (Sm and Sh). Das Ziel von SMASH war es, sowohl die Hardware von GPUs als auch ihre Programmierbarkeit genauer zu untersuchen. SMASH bestand aus zwei Teilen. Sm dient zur Simulation von GPUs, Sh war ursprünglich die Programmiersprache für Sm [7]. Sh selbst ist in C++ geschrieben und auch vollständig als eine Art Metaprogrammiersprache in C++ integriert. Dies wird ermöglicht, indem durch Operatorüberladung bestimmte Instruktionen zur Programmlaufzeit gesammelt werden können. Diese Sammlung wird dann von einem, durch Sh in das Programm integrierten Compiler, für die gewünschte Zielplattform übersetzt. Sh unterstützt viele unterschiedliche Plattformen. Öffentlich verfügbar sind aktuell aber nur Backends für GPUs und von gcc (GNU Compiler Collection) unterstützte CPU-Architekturen. Sh unterstützt sowohl die Möglichkeit, Shader für 3D-Anwendungen zu schreiben, als auch das Stream Processing Paradigma. Im Gegensatz zu den oben vorgestellten Programmiersprachen ist es mit Sh möglich, sowohl die Datenparallelität als auch die Taskparallelität explizit auszunutzen. Die Taskparallelität wird erreicht, indem einerseits Shader als Fragment- oder Vertex-Shader deklariert und andererseits Shader unterschiedlicher Art kombiniert werden können. Die Datenparallelität entsteht durch die grundsätzlichen Anforderungen an Shader. Sh steht aktuell als Release Candidate für Version 0.8 zur Verfügung und wird aktiv weiterentwickelt [7] Fazit Alle aktuell existierenden High-Level GPGPU Sprachen basieren zwar auf teilweise stark unterschiedlichen Ansätzen, leiden aber noch an sehr ähnlichen Problemen. So bietet z.b. keine der vorgestellten Sprache wirklich sicheren Schutz vor im Code nicht beachteten Hardware- Beschränkungen oder erreicht die Performance von handgeschriebenem Shader-Code. 6

7 4. Zusammenfassung Anwendungsentwicklung gemäß dem Stream Processing Paradigma, in welchem Datenstreams von Kerneln bearbeitet werden, ermöglicht im Falle einer entsprechenden Hardware-Architektur sowohl sehr effiziente Berechnungen als auch Optimierungen der Kommunikation. Aktuelle GPUs stellen eine solche Architektur in fast allen Systemen zur Verfügung. Leider ist die Programmierung solcher Hardware im Vergleich mit der Programmierung von CPUs noch sehr schwierig. High- Level-Sprachen entstehen gerade erst langsam und sind noch nicht weit genug fortgeschritten, um eine Softwareentwicklung ohne genauere Kenntnisse der GPU-Architektur zu ermöglichen. Es ist zu erwarten, dass innerhalb der nächsten Jahre die Entwicklung sowohl von High-Level-Sprachen als auch von GPUs schnell voranschreitet und damit die Softwareentwicklung für GPUs stark vereinfacht wird. 5. Literaturverzeichnis [1] D. Baumann, R580: ATI Radeon X1900 XTX & Crossfire Review, [2] I. Buck, Brook Spec v0.2, [3] I. Buck et al, Brook for GPUs: Stream Computing on Graphics Hardware, ACM Transaction on Graphics, Volume 23, pp , [4] J. A. Kahle et al, Introduction to the Cell multiprocessor, POWER5 and Packaging Volume 49, Number 4/5, [5] A E. Lefohn et al, Glift: Generic Efficient, Random-Access GPU Data Structures, ACM Transaction on Graphics, Vol. 25, pp. 1 37, [6] C. Lejdfors, L. Ohlsson, PyGPU: A high-level language for high-speed image processing, [7] M. McCool, S. Du Toit, Metaprogramming GPUs with Sh, A K Peters, [8] G. E. Moore, Cramming more components onto integrated circuits, Electronics, vol. 38, pp , [9] J. Owens, Streamin Architectures and Technology Trends, Addison-Wesley, GPUGems 2, pp , [10] R. Stephens, A Survey of Stream Processing, Acta Informatica 34, pp , [11] D. Tarditi, S. Puri, J. Oglesby, Accelerator: simplified programming of graphics processing units for gerneral-purpose uses via data parallelism, Microsoft Research, Technical Report MSR-TR ,