CUDA Nvidia s Parallel Programming Language

CUDA Nvidia s Parallel Programming Language Zusammengetragen und Erstellt von Christian Wirth und Peter Schroeder Im Rahmen der Vorlesung Serious Games Ausarbeitung abgegeben von Christian Wirth Peter Schroeder Mat-Nr.: 1274437 Mat-Nr.: 1287000 Fachbereich 20 Fachbereich 20 SS 08 SS 08 17.06.08

Zusammenfassung 2 Diese Ausarbeitung beschäftigt sich mit der Architektur und den Möglichkeiten von CUDA und parallel Computing. Parallel Computing wird immer wichtiger, da aufgrund von physikalischen Limitierungen ein Ende der Leistungsmöglichkeiten von serial Computing abzusehen ist. Zudem sind viele Probleme mit parallel Programming schneller lösbar. Da Grafikarten heutzutage bereits eine parallele Architektur besitzen, bietet Nvidia mit CUDA eine Ansatz diese auch für parallele Problemlösungen zu nutzen. Dieser Ansatz ist vor allem interessant, als diese Hardware ein weit verbreitete und günstige Basis für parallel Computing bietet. 1. Einleitung Bereits 1965 wurde Moore's Law aufgestellt, welches besagt, dass sich die Transistoranzahl in integrierten Schaltkreisen alle 18-24 Monate verdoppeln. [1] Dieses Gesetz bleibt auch bis heute wahr, obwohl es nicht mehr sinnvoll ist, die Transistorzahlen eines einzelnen CPU- bzw. GPU- Kerns zu erhöhen. Probleme bei der Miniaturisierung, Herstellung und Abwärme sorgen dafür, dass die Größe von diesen integrierten Schaltkreisen an ihre physikalischen Grenzen stößt. Deswegen hat man schon vor langem damit begonnen, komplette Kerne oder Subkomponenten dieser Recheneinheiten mehrfach nebeneinander zu betreiben. Dabei ergeben sich aber große programmiertechnische Probleme. Generell unterscheidet man zwischen vier verschiedene Parallelitätsebenen [2]: Bit Level Parallelism: Gleichzeitige Verarbeitung eines mehr-bit Datenworts Instruction Level Parallelism: Verteilen einer Serie von Befehlen auf mehrere Pipelines Data Level Parallelism: Aufteilen einer Aufgabe auf mehrere physikalisch unterschiedliche Ausführungseinheiten Task Level Parallelism: Aufteilen mehrerer Aufgaben auf mehrere physikalisch unterschiedliche Ausführungseinheiten Bit Level und Instruction Level Parallelism gehören heute zum Funktionsumfang jedes Prozessors. Task Level Parallelism kann auf einzelnen Computern durch die Nutzung eines Thread-Modells erreicht werden [3], sowie auf mehreren Computern durch distributed Computing [3,4]. Weiterhin ein großes Problem bleibt aber Data Level Parallelism, da hierfür bekannt sein muss, welche Teile der Aufgabe von einander abhängig sind. Da voneinander abhängige Aufgaben nicht parallel berechnet werden können, ist dies ein Arbeitsgebiet, das bisher nur unbefriedigend gelöst werden kann, und somit ein Gebiet ständiger Forschung ist. 1.1 Parallel Programming auf Grafikkarten Grafikarten verfügen heutzutage über eine immense Rechenleistung (siehe Abbildung 1), trotz einer verhältnismäßig niedrigen Taktrate. Erreicht werden diese hohen Geschwindigkeiten durch das Ausnutzen von speziellen Eigenschaften der Grafikberechnung. Diese zeichnen sich vor allem dadurch aus, dass häufig immer wieder die gleichen Berechnungen durchgeführt werden müssen (zum Beispiel 3D-zu-2D-Transformationen). Da Grafikkarten heute nahezu ausschließlich Rasterisierungsverfahren nutzen [6], sind die meisten dieser Berechnungen zudem von einander unabhängig. Bei der Rasterisierung, können fast alle Berechnungen parallel auf allen Pixel durchgeführt werden.

3 Abbildung 1: Vergleich GFlops aktueller GPU's und CPU's [5] Diese Erkenntnisse haben schon früh dazu geführt, dass sich die Architektur von GPUs grundsätzlich von CPUs unterscheidet (siehe Abbildung 2). Hierdurch sind Grafikarten gut geeignet für eine spezielle Klasse von parallel Programming: Massive Parallel Data Problems. Dies sind Probleme, die sich durch große Mengen von einander unabhängiger parallel zu berechnender Daten auszeichnen [5]. Hierzu zählen zum Beispiel: Phsyiksimulationen Partikelsimulationen Molekülsimulationen Suchalgorithmen Abbildung 2: Vergleich von CPU- und GPU-Architektur [5] Bisher wird parallel Programming auf Grafikkarten, neben Grafikberechnungen, hauptsächlich für akademische Zwecke eingesetzt. Aufgrund der weiten Verbreitung von Grafikkarten unter den Anwendern könnte aber die Nutzung dieser Verfahren für verschiedene Anwendungen interessant werden. 2. CUDA Eine Hürde der Nutzung von GPUs als parallele Prozessoren sind grundsätzlich die Schnittstellen auf selbige. Da GPUs zur Lösung von grafischen Problemen ausgelegt sind, sind auch die Schnittstellen, die den Programmieren von GPU-Herstellen bereitgestellt werden (vor allem APIs), auf grafische Probleme ausgelegt. Mit CUDA (Akronym für Compute Unified Device Architecture) will Nvidia dieses Problem adressieren. CUDA ist eine API zur Implementierung von massiv parallelen Programmen auf GPUs der GeForce 8, Tesla und Quadro Serien, die nicht auf graphische Problemstellungen spezialisiert

sind. Die Motivation von Nvidia ist dabei eine Markterweiterung für ihre Produkte. GPUs sollen nicht mehr auf grafische Probleme reduziert sein, sondern vielseitig benutzt werden. Im Folgenden wird die Programmierung mit CUDA erklärt. Dazu wird zuerst auf das in CUDA verwendete GPU-Modell eingegangen. Die Ausführungen stellen keine vollständige Beschreibung dar, sondern sollen nur einen grundlegendes Verständnis vermitteln. Eine umfangreiche Erläuterung findet man in der offiziellen CUDA-Dokumentation [5]. 2.1 CUDA GPU-Modell Die GPU ist ein Prozessor mit eigenem Random-Access Speicher, der viele Threads parallel ausführt. Die Erzeugung von Threads bewirkt, im Gegensatz zur CPU, vernachlässigbar wenig Mehraufwand. Tatsächlich erreicht die GPU nur volle Effizienz ab circa 1000 Threads. Die GPU wird als ein Kooperationsprozessor zur CPU gesehen: Die CPU verarbeitet sequentielle Teile einer Anwendung, die GPU parallele Teile. Die CPU lädt dazu den entsprechenden Teil der 4 Abbildung 3: Thread-Hierarchie der GPU [5] Anwendung, den so genannten Kernel, auf die GPU. Der Kernel wird dann parallel von mehreren Threads auf unterschiedlichen Daten ausgeführt. Damit Programmierer genaue Angaben machen können, welche Kernels von welchen Threads ausgeführt werden, sind Threads in einer Hierarchie angeordnet (siehe Abbildung 3). Threads gehören zu genau einem Block und ein Block besteht aus einer Menge von Threads. Blöcke gehören zu genau einem Grid und ein Grid besteht aus einer Menge von Blöcken. Blöcke und Threads haben ein-, zwei- oder dreidimensionale Ids, mittels derer sie adressiert werden. Die Anzahl der möglichen Blöcke in einem Grid und Threads in einem Block sind von der Hardwareimplementation der GPU abhängig. Ein Kernel ist genau einem Grid zugeordnet. Der Kernel wird von allen Threads in diesem Grid ausgeführt. Die Threads eines Blocks werden grundsätzlich parallel ausgeführt. Falls die GPU genug Kapazitäten frei hat, werden auch alle Blöcke parallel ausgeführt, ansonsten sequentiell. Die Threads eines Blocks können synchronisiert werden und effizient auf gemeinsamen Daten arbeiten, Threads unterschiedlicher Blöcke können nicht kooperieren.

Jeder Thread hat Zugriff auf den Random-Access Speicher der GPU über verschiedene Speicherräume: Lese/Schreibrecht auf Register und den den lokalen Speicher pro Thread Lese/Schreibrecht auf den gemeinsamen Speicher pro Block Lese/Schreibrecht auf den globalen Speicher pro Grid Leserecht auf den konstanten Speicher und Texturspeicher pro Grid Der Zugriff auf Register, lokalen und gemeinsamen Speicher ist schnell (3 bis 4 Taktzyklen); Globaler, konstanter und Texturspeicher hingegen langsam (400 bis 600 Taktzyklen). Konstanter und Texturspeicher werden jedoch im lokalen Speicher gecachet, können also nach einmaligem laden schnell abgerufen werden. Der Texturspeicher bietet spezielle Formen der Datenadressierung, die hauptsächlich für grafische Probleme gedacht sind. Die CPU hat Lese- und Schreibrecht auf den globalen und konstanten Speicher und Texturspeicher. Über diese Speicherräume erfolgt die Kommunikation zwischen CPU und GPU. 2.2 CUDA-API Die CUDA-API ermöglicht das Programmieren von parallelen Programmen, die von einer oder mehreren GPUs ausgeführt werden. Sie besteht aus einer Erweiterung der Programmiersprache C und einer spezialisierten Laufzeit-Bibliothek. Die Erweiterung der Programmiersprache C unterteilt sich in vier Bereiche: Funktions-Modifikatoren, mit denen angegeben wird, ob Funktionen auf GPU oder CPU ausgeführt werden und ob sie von CPU oder GPU aufgerufen werden können. Variablen-Modifikatoren, mit denen angegeben wird, in welchem Speicher auf der GPU die Variablen abgelegt werden sollen. Ein Befehl, mit dem ein Kernel in die GPU geladen und der dazugehörige Grid, inklusive Blocks und Threads, initialisiert wird. Vier native Variablentypen, mit denen Block- und Gridgrößen, sowie Block- und Gridindizes angegeben werden. Die Laufzeit-Bibliothek unterteilt sich in drei Bereiche: Eine CPU-Komponente, die Zugriff auf und Steuerung der GPU (beziehungsweise auch mehreren GPUs) ermöglicht. Eine GPU-Komponente, die spezielle Funktionen der GPU bereitstellt. Dies sind vor allem Fließkomma-Operationen und Grafik-spezifische Funktionen. Eine gemeinsame Komponente, die verschiedene Variablen und einen Teil der Standard C- Bibliothek für CPU und GPU bereitstellt. Diese Komponente enthält genau die Teile der Standard C-Bibliothek, die von der GPU unterstützt werden. 5 3. Performanz und Beispiel-Implementationen Die großen Vorteile von CUDA im Rahmen von massivem Multithreading sind leider auch von Nachteilen begleitet. Hierzu gehört vor allem die Speicheranbindung und Nutzung der GPU, welche sich deutlich von der der CPU unterscheidet. Hauptsächlich ist zu beachten, dass durch die begrenzte Bandbreite der GPU zum Random-Access Speicher des Computers nur wenige Daten pro Ausführung übertragen werden können [7]. Des Weiteren wird auf den gemeinsamen und globalen Speicher nicht durch direkte Adressierung zugegriffen. Jeder beliebige Thread kann auf jede Dateneinheit zugreifen. Hierdurch können natürlich Redundanzen in den zu speichernden Daten minimiert werden, aber auf Grund von

blockierenden Speicherzugriffen wird eventuell die Zahl der echt parallel arbeitenden Threads gesenkt [7]. Auf Grund dieser und weiterer Probleme, müssen Programme auf CUDA optimiert werden, um die bestmögliche Performanz zu erreichen. Ein Gruppe der University of Illinois [7] hat sich diesem Problem angenommen und eine Reihe von mathematischen Verfahren auf CUDA portiert (siehe Tabelle 1), sowie optimiert, um aussagekräftige Performanz-Messungen zu erlauben (siehe Tabelle 2). Es ist aber anzumerken, dass ausschließlich Verfahren betrachtet wurden, die explizit für parallel Programming geeignet sind. 6 Tabelle 1: Liste der portierten Verfahren [7] Tabelle 2: Performanzergebnisse der angegebenen Verfahren [7] Wie zu sehen ist, sind Beschleunigungen zwischen Faktor ~2 und ~400 möglich. Die Nutzung der Grafikkarte wirkt sich also performanztechnisch deutlich aus. Des Weiteren ist zu erkennen, dass nicht viele der Verfahren die Zahl der maximalen simultanen Threads von 12288 ausnutzen. Es wäre also durchaus möglich, noch andere Berechnungen parallel auf der GPU auszuführen. Hierbei ist aber zu beachten, welche Bottlenecks die Berechnungen limitieren. Zusätzliche Berechnungen, ohne eventuell beträchtliche Performanzeinbrüche zu verursachen, sind nur bei Berechnungen mit Instruction issue -Bottleneck möglich.

Da es sich bei den hier betrachteten Verfahren um Portierungen bereits existierender Algorithmen handelt, werden im Folgenden zwei neue Projekte vorgestellt. Hierbei soll gezeigt werden, dass CUDA bisher nicht (effizient) durchführbare, neue Verfahren ermöglicht. 3.1 Neuronale Netze auf der GPU Neuronale Netze können nur schlecht auf sequentiellen Rechnern simuliert werden. Die eigentliche Berechnung in neuronalen Netzen findet fast ausschließlich durch gewichtete Aufsummierungen statt. Ein jedes Neuron summiert seine Eingangssignale gewichtet auf, um ein Ausgangssignal zu erzeugen. [8] Zur Berechnung eines solchen Netzwerkes auf einem sequentiellen Rechner müssen alle Aufsummierungen hintereinander ausgeführt werden. Da aber die meisten Neuronen (Aufsummierungen) nicht direkt von einander abhängig sind, ist dies nicht sinnvoll. Zudem bestehen kleine Netzwerke bereits aus mehreren hunderten bis tausenden Neuronen. Eine parallel Berechnung ist also mehr oder minder erforderlich. Studenten der University of California haben daher ein neuronale Netzwerk zur Erkennung von Handschriften in CUDA implementiert [8], und konnten eine 270-mal höhere Performanz erreichen, als bei einer (sequentiellen) CPU Implementierung. 3.2 Molecular Modelling Molecular Modelling bezeichnet die Berechnung mathematischer Modelle von Molekülen, die im Rahmen der Medizin und Chemie sehr wichtig sind [10]. Zum Beispiel das bekannte Folding@Home Projekt, das sich mit einem Unterproblem des Molecular Modelling beschäftigt [11]. Hierbei geht es hauptsächlich um die Berechnung der Kräfte zwischen den einzelnen Atomen eines Moleküls. Da normale Moleküle bereits aus mehreren 100.000 Atomen bestehen, sind diese Berechnungen sehr aufwendig. Wie bei neuronalen Netzen auch, sind aber die Kräfteberechnungen zwischen den Atomen größtenteils unabhängig von einander. Somit ist Molecular Modelling ein Problem, welches sich für eine parallele Programmierung anbietet. Eine Gruppe der University of Illinois konnte hierdurch Beschleunigungen um den Faktor 20 erzielen [9]. Ein Vorteil der sich in der Zukunft konkret durch bessere Medikamente und ein erweitertes Verständnis biologischer Vorgänge auszeichnen sollte. 7 4. Fazit Nachdem CUDA und parallel Programming vorgestellt wurden, sollen diese nun im Bezug auf ihre Relevanz und Anwendbarkeit für Serious Games diskutiert werden. Die Vorteile von parallel Programming sind offensichtlich. Ist eine Problemstellung parallelisierbar, kann sie deutlich effizienter gelöst werden als durch sequentielle Ansätze. Im Bereich der Serious Games wird dieser Vorteil bereits für Grafikberechnungen ausgenutzt. Aber auch andere komplexe Bereiche könnten so beschleunigt werden, besonders Physik und künstliche Intelligenz. Nvidia ist einer der beiden marktführenden Produzenten für GPUs [12]. CUDA kompatible Chips sind unter privaten Anwendern weit verbreitet. Auch im akademischen Feld (gerade durch die wachsende Beliebtheit von CUDA selbst) finden Nvidia Chips immer mehr Anwendung. Damit ist eine wichtige Voraussetzung für die Nutzung von parallel Programming und CUDA in Serious Games bereits geschaffen. Die Einarbeitung von Programmierern in CUDA ist ein nicht zu unterschätzender Aufwand. Andererseits dürfte jede Umstellung von sequentiellen auf parallele Programmiermodelle einen signifikanten Aufwand darstellen. Anzumerken ist dabei die Fundierung von CUDA auf der auch im Bereich der Serious Games weit verbreiteten Programmiersprache C.

Ein weiterer Vorteil durch die Basierung auf C ist das Potenzial von CUDA, mit bestehenden Frameworks zu kooperieren. Jedoch lassen sich hier Kritikpunkte am derzeitigen Stand der Forschung um CUDA erkennen. CUDA wird zum jetzigen Zeitpunkt hauptsächlich in akademischen Umfeld zur Lösung von eher abstrakten Problemen benutzt. Es gibt keine groß angelegten Forschungsbestrebungen, um CUDA in bestehenden Anwendungsdomänen zu nutzen 1. Dazu kommt, dass mit der im Juni 2008 veröffentlichten Version 2.0 erstmals auch Windows direkt unterstützt wird. Vorher war CUDA nur für verschiedene Linux-Derivate nutzbar. Daher gab es bisher auch keine Bestrebung vollwertige, kommerziell verwertbare Anwendungen mit Hilfe von CUDA zu produzieren. Genauso mangelt es bisher an gezielten Programmierparadigmen (wie zum Beispiel Entwurfsmuster) und Frameworks für CUDA. Als Fazit lässt sich daher ziehen, dass CUDA und parallel Programming für Software Engineering im allgemeinen und Serious Games im speziellen in der Zukunft eine große Rolle spielen werden, sie zum derzeitigen Stand aber noch nicht effektiv einsetzbar sind. 8 5. Referenzen [1] Moore's law Wikipedia, the free encyclopedia Online unter http://en.wikipedia.org/wiki/moore%27s_law Abruf am 17. Juni 2008 [2] Parallel computing Wikipedia, the free encyclopedia Online unter http://en.wikipedia.org/wiki/parallel_computing Abruf am 17. Juni 2008 [3] Parallel Programming in C with MPI and OpenMP Quinn, M. J. McGraw-Hill Inc., 2004 [4] A close look at task assignment in distributed systems Ramakrishnan, S.; Cho, I.-H.; Dunning, L.A. INFOCOM '91. Proceedings. Tenth Annual Joint Conference of the IEEE Computer and Communications Societies. Networking in the 90s., Vol. 2, pp. 806-812, 1991 [5] CUDA - Progamming Guide Version 1.1 Nvidia Corporation Online unter http://developer.download.nvidia.com/compute/cuda/1_1/nvidia_cuda_programming_guide_1.1.pdf Abruf am 20. Mai 2008 [6] Fundamentals of Computer Graphics Shirley, P. A. K. Peters, Ltd., 2002 [7] Optimization Principles and Application Performance Evaluation of a Multithreaded GPU Using CUDA Ryoo, S.; Rodrigues, C. I.; Baghsorkhi, S. S.; Stone, S. S.; Kirk, D. B.; Hwu, W. W. PPoPP '08: Proceedings of the 13th ACM SIGPLAN Symposium on Principles and practice of parallel programming, pp. 73-82, 2008 [8] A Neural Network on GPU Yan, S. Online unter http://www.codeproject.com/kb/graphics/gpunn.aspx Abruf am 20. Mai 2008 1 Aktuelle gibt es neue Entwicklungen zu diesem Thema, wie zum Beispiel die Nutzung von CUDA im Adobe Photoshop. [13]

[9] GPU acceleration of cutoff pair potentials for molecular modeling applications Rodrigues, C. I.; Hardy, D. J.; Stone, J. E.; Schulten, K.; Hwu, W. W. In CF'08: Proceedings of the 2008 conference on Computing frontiers, pp. 273-282, New York, NY, USA, 2008 [10] Scalable molecular dynamics with NAMD Phillips, J. C.; Braun, R.; Wang, W.; Gumbart, J.; Tajkhorshid, E.; Villa, E.; Chipot, C; Skeel, R. D.; Kalé, L.; Schulten, K. In Journal of Computational Chemistry, Vol. 26, No. 16, pp. 1781-1802, 2005 [11] Folding@Home distributed computing Folding@Home Online unter http://folding.stanford.edu/ Abruf am 20. Mai 2008 [12] Survey Summary Data Valve Corporation Online unter http://www.steampowered.com/status/survey.html Abruf am 13. Juni 2008 [13] Photoshop to get GPU and physics acceleration Valich, T. Online unter http://www.tgdaily.com/content/view/37611/140/ Abruf am24. Juni 2008 9