Allgemeines

Abbildung 4.26 Der ϕ-Winkel der Ionen in der Polarisationsebene aufgetragen gegen den Winkel Δϕpol zwischen der Dimerachse und dem Elektron, ebenfalls in der Polarisationsebene. Die auf die beiden Spektren angewandten Vorsortierungen entsprechen denen aus Abbildung 4.25 (c) und (d). Wie in (b) zu sehen, ist die Δϕpol -Winkelverteilung innerhalb der ausgewählten Bereiche für alle ϕ_pol,ion gleich. Auf die Struktur der Winkelverteilung wird im Kapitel Ergebnisse eingegangen.

großen Flugzeit in demselben Bereich wie die ²⁰Ne⁺-Ionen liegen.¹⁰ Um zu gewährleisten, dass sich diese Fragmente und die Neonionen nicht überschneiden, musste ein relativ hohes elektri-sches Feld (20 V/cm) gewählt werden, was wiederum zur Folge hat, dass die Impulsverteilung der Dimerionen nur auf einem relativ kleinen Bereich des Detektors abgebildet wird. So ent-spricht der äußere Radius von 13 a.u. der Verteilungen in Abbildung 4.25 einem Radius von we-niger als 10 mm auf dem Detektor. Dadurch verursachen kleinere Störungen im Detektorbild, die vermutlich durch Unebenheiten auf der Oberfläche der MCP-Kanäle oder Elektronikproble-me erzeugt wurden, relativ große Fehler im Impuls. Die Strukturen sind besonders gut in Abbil-dung 4.25 (c) zu erkennen. Aufgrund dieser Probleme kann nur der Teil der Ereignisse, bei wel-chen die Elektronen in Bereiwel-chen auf dem Ionendetektor ohne diese Strukturen detektiert wur-den, verwendet werden (s. Abbildung 4.25 (d)).

Um sicher zu gehen, dass die in den ausgewählten Detektorbereichen gemessenen Daten in Ordnung sind, wird der ϕ-Winkel der Ionen in der Polarisationsebene gegen den Winkel Δϕpol

zwischen der Dimerachse und dem Elektron, ebenfalls in der Polarisationsebene, aufgetragen.

Innerhalb der Polarisationsebene muss die Winkelverteilung zwischen dem Elektron und dem Dimer isotrop sein. Das bedeutet, dass die Δϕpol-Verteilung für alle Ausrichtungen des Dimers innerhalb dieser Ebene identisch sein sollte. Wie aus Abbildung 4.26 (b) zu erkennen, ist dies für den ausgewählten Bereich der Fall.

4.11. Parallelisierung der Impulsberechnung mittels NVIDIA CUDA®

4. Datenanalyse

deutlich geringer ist, kommen auch hier während einer Messzeit schnell mehrere hundert Giga-byte oder sogar einige TerraGiga-byte zusammen.

In denen vorherigen Kapiteln wurde bereits auf die Möglichkeit, die Datenmenge durch eine Vorabsortierung zu reduzieren und erst dann rechenintensive Analyseschritte wie z. B. die Be-rechnung der Impulsvektoren durchzuführen, eingegangen. Teilweise ist eine effektive Unter-grundunterdrückung aber auch erst möglich, wenn diese rechenintensiven Schritte bereits durchgeführt wurden. Falls sich zum Beispiel die Impulserhaltung zunutze gemacht werden soll, müssen natürlich vorher die Impulse berechnet sein. Eine gute Möglichkeit, die benötigte Zeit für diese Berechnungen zu verringern, ist es sie zu parallelisieren. Dies ist immer dann beson-ders effektiv, wenn mehrfach eine sehr ähnliche Rechenoperation durchgeführt werden muss.

Diese Rechenoperationen dürfen allerdings nicht voneinander abhängig sein. Wenn ein Prozess für die Durchführung Informationen benötigt, die in einem anderen Prozess ermittelt werden, kann man diese Prozesse selbstverständlich nicht parallel ausführen.

Bei der Datenanalyse eines COLTRIMS-Experiments ist die erste dieser beiden Bedingungen für gewöhnlich sehr gut erfüllt. Es werden normalerweise für alle Ereignisse die gleichen physikali-schen Größen mit denselben mathematiphysikali-schen Funktionen berechnet. Natürlich kann es zu Ab-weichungen kommen, da manchmal unterschiedliche Teilchen in einem Ereignis gespeichert werden (z. B. gibt es in manchen Ereignissen ein zweites Elektron) oder es werden manche Grö-ßen nur berechnet, wenn andere in derselben Analysefunktion vorher berechnete GröGrö-ßen in-nerhalb eines bestimmten Bereichs liegen. Allgemein sind die Rechenoperationen für jedes Er-eignis aber sehr ähnlich. Da die einzelnen physikalischen Reaktionen, die gemessen werden, für gewöhnlich nicht korreliert sind, ist auch die zweite Bedingung, dass alle Größen für alle Ereig-nisse unabhängig voneinander berechnet werden können, erfüllt.

Eine Möglichkeit zur Realisierung einer solchen Parallelisierung ist es die Analysesoftware so zu schreiben, dass sie alle Prozessorkerne der CPU (Central Processing Unit) des Computers wendet. Die selbe Funktion, welche die Impulsberechnung etc. beinhaltet, wird also für ver-schiedene Messereignisse auf allen zur Verfügung stehenden Kernen gleichzeitig ausgeführt.

Dieses Vorgehen wird als Multithreading bezeichnet. Hiermit kann man auf modernen Quad-Core-Rechnern die Rechenzeit tatsächlich auf fast ein Viertel reduzieren (natürlich wird ein klei-ner Teil der Rechenleistung von dem Overhead, welches durch die Organisation der parallelen Vorgänge entsteht, in Anspruch genommen). Dieser Zeitgewinn kann durch Einsatz von Prozes-soren mit noch mehr Kernen, welche momentan noch relativ teuer sind, oder mittels der Hyper-threading-Technologie (sog. hardwareseitiges Multithreading [Int]) noch erhöht werden.

Ein wirklicher Geschwindigkeits- „Quantensprung“ kann aber erreicht werden, wenn die Re-chenoperationen anstatt auf der CPU auf der GPU (Graphics Processing Unit), also dem Grafik-prozessors des Computers, durchführt werden. Bereits günstige Grafikkarten verfügen über 100 oder mehr einzelne Prozessorkerne und bessere Karten haben teileweise deutlich über tausend Kerne und das für ungefähr den Preis eines Intel® Xenon® Octa-Core Rechners (Stand: Juli 2013).

Allerdings ist die GPU nicht ein, bis auf die Anzahl der Kerne, zur CPU identischer Prozessor. Der schematische Aufbau einer GPU im Vergleich zu dem einer CPU ist in Abbildung 4.27 dargestellt.

Wie zu sehen ist, besteht die CPU aus nur wenigen Recheneinheiten (ALU), verfügt dafür aber über ein größeres Steuerwerk (engl. control unit) und einen größeren Cache. Dies ist nötig, um Aufgaben mit komplexen Anweisungen und vielen Verzweigungen durchzuführen, was mit der GPU nur schlecht oder gar nicht möglich ist. Bei der GPU sieht man, dass diese wie bereits er-wähnt aus einer Vielzahl von Recheneinheiten besteht. Die ALUs der GPU sind sogenannte Streamprozessoren. Dabei handelt es sich um kleine Recheneinheiten, die einzelne skalare

Re-chenoperationen an einem Datenstrom ausführen können. Eine bestimmte Anzahl an Stream-prozessoren teilt sich ein deutlich kleiner als bei der CPU dimensioniertes Steuerwerk und einen ebenfalls kleineren Cache. Die Einheit aus Rechenkernen, Steuerwerk und Cache nennt man Multiprozessor (MP). Des Weiteren haben die einzelnen Streamprozessoren für gewöhnlich eine niedrigere Taktung als die Kerne einer CPU. Die GPU ist daher nur bei Prozessen, welche gut parallelisierbar sind, schneller. Müssen die Aufgaben seriell abgearbeitet werden, ist die CPU schneller.

Wenn die Bedingungen an das Programm zur sinnvollen Ausführung auf der GPU erfüllt sind, stellt sich natürlich die Frage wie man den Computer dazu bekommt bestimmte Teile des Pro-gramms auf der GPU auszuführen. Es soll in diesem Zusammenhang darauf hingewiesen wer-den, dass die Programme, die man schreibt, nie vollständig auf der GPU ausgeführt werden.

Üblicherweise läuft das Hauptprogramm auf der CPU und es werden nur bestimmte, rechenin-tensive Operationen auf der GPU durchgeführt. Glücklicherweise stellen inzwischen verschie-dene Anbieter Programmierschnittstellen (APIs, engl. application programming interfaces) zur Verfügung mit denen es möglich ist, Anwendungen, welche den Grafikprozessor nutzen, kom-plett in höheren Programmiersprachen zu schreiben. Diese APIs beinhalten für gewöhnlich ei-nen Compiler, welcher den Quelltext in für den Grafikprozessor bearbeitbaren Binärcode um-wandelt und eine Zusammenstellung von Bibliotheken mit Funktionen und, abhängig davon ob die API eine objektorientierte Sprache unterstützt, Klassen, welche das „Ansteuern“ der Grafik-karte übernehmen. Die populärsten APIs dieser Art sind momentan wohl OpenCL (Open Com-puting Language) und Nvidia® CUDA®. OpenCl wurde ursprünglich von Apple entwickelt und ist für die Verwendung auf verschiedenen Arten von Parallrechnern, also nicht nur Grafikkarten, ausgelegt. CUDA (Compute Unified Device Architecture) ist nur für die Verwendung mit be-stimmten Nvidia-Grafikkarten gedacht. Dafür bietet es eine umfangreiche Bibliothek für wissen-schaftliche Rechnungen, welche für den Einsatz in der Grundlagenforschung sehr nützlich ist.

Abbildung 4.27 Aufbau einer CPU und einer GPU im Vergleich [Nvid07]. Der Arbeitsspeicher (DRAM) ist streng genommen kein Teil der CPU bzw. GPU.

Dies war einer der Hauptgründe, warum die Entscheidung getroffen wurde die Grafikkarten-gestützte Analyse-Software für COLTRIMS in der CUDA-Umgebung zu programmieren. Des Wei-teren gibt es mit dem von Nvidia selbst entwickeltem und veröffentlichtem NSight™ ein Plug-In für die Entwicklungsumgebungen Eclipse und Microsoft Visual Studio, welches ein komfortables Programmieren mit Funktionen wie einem Debugger für GPU-Code und Syntaxhervorhebung erlaubt. Außerdem wird das Erstellen eines Projektes durch Nsight™ stark vereinfacht. Musste

4. Datenanalyse

Abbildung 4.28 Durch den Plug-In NSight™

Visual Studio Edition wird das Erstellen einer Quelldatei, welche Code, der auf der GPU aus-geführt werden soll, beinhaltet, deutlich ver-einfacht. Eine solche CUDA-Datei kann einfach im Add New Item-Menü wie eine gewöhnliche Quelldatei hinzugefügt werden.

man früher für die Quelldatei, welche die GPU-Funktionen beinhaltet, den CUDA-Compiler NVCC (NVidia CUDA Compiler) inklusive diverser Compiler Anweisungen noch manuell in die Kommandozeile eintragen, kann nun über das Add New Item-Menü eine CUDA-Datei hinzuge-fügt werden, wodurch die notwendigen Compiler-Anweisungen automatisch generiert wer-den(s. Abbildung 4.28). Für die Programmierung der Analysis CUDA genannten Applikation zur Analyse von COLTRIMS-Messdaten wurde die Entwicklungsumgebung Visual Studio 2010 Ulti-mate verwendet. Grundsätzlich ist es für das Arbeiten mit CUDA allerdings nicht zwingend not-wendig über eine Version von Eclipse oder Visual Studio und den Nsight Plug-In zu verfügen. Es ist ausreichend, das kostenlose CUDA-Toolkit zu installieren, welches den NVCC beinhaltet, der über die Windows-Eingabeaufforderung oder eine Unix-Shell gestartet werden kann.

Abbildung 4.29 CUDA-relevante Eigenschaften der verwendeten NVIDIA® Quadro K5000 Grafikkarte, welche über 1536 Streamprozessoren verfügt. Dargestellt mit der Applikation deviceQuery, die Teil des Nvidia® GPU Computing SDK ist.