JaMP Implementierung eines OpenMP Dialektes im DSM System Jackal

Transkript

1 JaMP Implementierung eines OpenMP Dialektes im DSM System Jackal Studienarbeit im Fach Informatik vorgelegt von Matthias Bezold angefertigt am Institut für Informatik Lehrstuhl für Informatik 2 Programmiersysteme Friedrich-Alexander-Universität Erlangen Nürnberg (Prof. Dr. M. Philippsen) Betreuer: Dipl.-Inf. Michael Klemm Ph.D. Ronald Veldema Prof. Dr. Michael Philippsen Beginn der Arbeit: 1. Dezember 2004 Abgabe der Arbeit: 18. April 2005

2

3 Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet. Der Universität Erlangen-Nürnberg, vertreten durch die Informatik 2 (Programmiersysteme), wird für Zwecke der Forschung und Lehre ein einfaches, kostenloses, zeitlich und örtlich unbeschränktes Nutzungsrecht an den Arbeitsergebnissen der Studienarbeit einschließlich etwaiger Schutzrechte und Urheberrechte eingeräumt. Erlangen, den 18. April 2005 Matthias Bezold

4

5 Studienarbeit Thema: JaMP Implementierung eines OpenMP Dialektes im DSM System Jackal Hintergrund: Für Shared Memory Systeme existieren zahlreiche Compiler, die es dem Programmierer erlauben, ein sequentielles Programm mittels Compiler Direktiven zu parallelisieren. Der Compiler unternimmt hierbei die nötigen Schritte, um einen als parallel ausführbar markierten Programmteil ohne weiteres Zutun des Programmierers auf mehrere parallel ablaufende Threads aufzuteilen. Ein Beispiel hierfür ist der OpenMP Standard. Die automatische Parallelisierung beruht auf der Tatsache, dass alle Threads den gleichen Adressraum sehen und so auf einen gemeinsamen Speicherbereich zugreifen können. Das Jackal System bietet mit seiner Implementierung eines DSMs (Distributed Shared Memory) für Java eine Umgebung, die als Basis für diese Art von automatischer Parallelisierung (auch im Cluster) dienen kann. Aufgabenstellung: Im Rahmen der Studienarbeit soll das Jackal System um eine (partielle) OpenMP Implementierung erweitert werden. Die von OpenMP geforderten Direktiven sind auf Verträglichkeit mit dem Java Memory Model (JMM) zu untersuchen und (soweit möglich) dem JMM entsprechend zu implementieren. Die wesentlichen Direktiven des Standards müssen auf das Jackal System übertragen werden. Hierzu ist der existierende Java Compiler in Jackal geeignet zu erweitern, so dass die Übersetzung der neuen Direktiven möglich wird. Die Implementierung soll weiterhin Möglichkeiten zur automatischen Erzeugung von Threads zur Ausführung der parallelen Regionen (Schleifen, Abschnitte) bereitstellen sowie die Reduktion von parallel berechneten Zwischenergebnissen erlauben. Abschließend soll untersucht werden, wie das dynamische Hinzufügen und Entfernen von Cluster Knoten zum/vom ausgeführten Programm unterstützt werden kann. Meilensteine: Einarbeitung in den Compiler Erzeugung von Threads (omp parallel) Einbinden von private/shared Variablen Unterstützung von Schleifen (omp for), Zuteilung dynamisch und statisch Unterstützung von Sektionen

6 optimierte Reduktionen Anpassung zum dynamischen Hinzufügen/Entfernen von Knoten aus dem Cluster Messungen Ausarbeitung Literatur: J. Obdržálek, M. Bull JOMP Application Program Interface Version 1.1 (draft), 25. August, 2000 Betreuung: Bearbeiter: Michael Klemm, Dipl. Inf. und Ronald Veldema, Ph.D. Matthias Bezold

7 Zusammenfassung Bei OpenMP handelt es sich um ein Programmiermodell für die Sprachen C/C++ und Fortran, welches eine einfache und flexible Schnittstelle zur Entwicklung von Shared Memory Anwendungen bietet. In dieser Arbeit präsentieren wir eine OpenMP Implementation, die sich zum einen davon von anderen unterscheidet, dass sie den OpenMP Standard an Java anpasst, und zum anderen, dass sie in einem DSM System umgesetzt wurde, um die Eignung von OpenMP für solche Systeme zu prüfen. Die Basis für JaMP bildet das Übersetzersystem Jackal, welches Java Quellprogramme in Maschinenprogramme für eine ganze Reihe von Architekturen übersetzen kann. Jackal verfügt dabei auch über die Fähigkeit, ein Rechnerbündel mit Hilfe eines speziellen Laufzeitsystems als DSM System nutzen zu können. Für die Implementation von JaMP wurde der Übersetzer Jackal um die Fähigkeit erweitert, parallele Programme aus sequentiellen Quellprogrammen zu erzeugen, die mit speziellen Kommentaren, so genannten Pragmas, angereichert wurden. Mit Hilfe dieser Pragmas ist es möglich, einzelne Programmabschnitte zu markieren, die parallel ausgeführt werden sollen. Innerhalb dieser Regionen können wiederum Abschnitte angegeben werden, die von nur einem Kontrollfaden ausgeführt werden sollen. Außerdem bietet JaMP eine Unterstützung für Schleifen, durch welche die Schleifeniterationen auf die laufenden Kontrollfäden aufgeteilt werden können, so dass jede Iteration der Schleife nur einmal ausgeführt wird, und nicht einmal von jedem Kontrollfaden. Teilergebnisse, die von den einzelnen Kontrollfäden berechnet wurden, können mit dem so genannten Reduktions Mechanismus zusammengefasst werden. Ein wichtiger Teil dieser Arbeit ist nicht nur die Portierung des OpenMP Standards für die Programmiersprache Java, sondern auch dessen Verwendung für ein DSM System. Die Basis hierfür bildet das System Jackal. Im Rahmen dieser Arbeit wurde weiterhin das Entfernen und das Hinzufügen von Kontrollfäden während der Ausführung eines parallelen Abschnitts untersucht. Hierzu wurden neue Methoden zum Laufzeitsystem von JaMP hinzugefügt, die es erlauben, Kontrollfäden zur Laufzeit zu entfernen. Das Hinzufügen von Kontrollfäden könnte Teil einer auf dieser Implementation aufbauenden Arbeit sein. In verschiedenen Benchmarks wurde gezeigt, dass die Geschwindigkeit von Programmen, die unter Verwendung von JaMP parallelisiert wurden, mit der Geschwindigkeit von manuell parallelisierten Programmen vergleichbar ist. i

8 ii

9 Inhaltsverzeichnis 1 Einleitung Hintergrund Überblick über parallele Systeme Jackal Ein Distributed Shared Memory System OpenMP JaMP Gliederung JaMP OpenMP für Jackal Kennzeichnung von Abschnitten Parallele Abschnitte Zuweisung von Daten Schleifen Reduktionen Weitere Konstrukte Ausführung mit nur einem Kontrollfaden Abschnitte Barrieren Kritische Abschnitte Unterschiede zu OpenMP Hinweise zum Arbeiten mit JaMP Zusammenfassung Implementation Allgemeine Struktur des Jackal Systems Parallele Regionen Datenübergabe an Kontrollfäden Zugriff auf private Variablen iii

10 Inhaltsverzeichnis Zugriff auf gemeinsame Variablen Transformation von Reduktionen Transformation von Schleifen Statische Blockzuteilung Dynamische Blockzuteilung Geführte Blockzuteilung Implementation weiterer Funktionen Barrieren Ausführung durch nur einen Kontrollfaden Umsetzung der Regionenstruktur Zusammenfassung Benchmarks Testumgebung Mikro Benchmarks Einfacher Raytracer Matrix Summe Java Grande Benchmark Weitere Benchmarks Optimierungsmöglichkeiten Zusammenfassung Verwandte Arbeiten und Ausblick Verwandte Arbeiten Parallele Programmiermodelle OpenMP OpenMP für Java OpenMP für DSM Systeme Weitere Implementationen Dynamische Veränderung der Anzahl von Kontrollfäden Entfernen von Kontrollfäden Hinzufügen von Kontrollfäden Ausblick Zusammenfassung 59 iv

11 Inhaltsverzeichnis A Anhang: JaMP Referenz 61 A.1 parallel Konstrukt A.2 Konstrukte zur Arbeitsteilung A.2.1 for Konstrukt A.2.2 sections Konstrukt A.2.3 single Konstrukt A.3 Hauptkontrollfaden und Synchronisation A.3.1 master Konstrukt A.3.2 critical Konstrukt A.3.3 barrier Direktive A.4 Attribute A.4.1 default A.4.2 firstprivate A.4.3 lastprivate A.4.4 nowait A.4.5 num threads A.4.6 private A.4.7 reduction A.4.8 schedule A.4.9 shared A.5 Laufzeitsystem A.5.1 setnumthreads() A.5.2 getnumthreads() A.5.3 getmaxthreads() A.5.4 getthreadnum() A.5.5 getnumprocs() A.5.6 inparallel() A.5.7 setdynamic() A.5.8 getdynamic() A.5.9 setnested() A.5.10 getnested() B Anhang: Unterschiede zwischen JaMP und OpenMP 75 v

12 Inhaltsverzeichnis vi

13 Abbildungsverzeichnis 1.1 Summe einer Reihnung in C++ mit OpenMP Parallelisierung Gerüst eines JaMP Progammes Das Konstrukt parallel Schematische Darstellung von parallelen Abschnitten Das Attribut num threads Die Attribute private und shared Private und gemeinsame Variablen Beispiel für private, firstprivate und shared Deklaration eines for Konstruktes Ablauf einer Reduktion Reduktion in einer Reihungs Summenberechnung Skizze einer Reduktion Die Direktiven master und single Das Konstrukt sections Die Direktive barrier Das Konstrukt critical Verschachtelte Schleifen Produktschleife zu Abbildung Transformation eines parallelen Abschnitts Beispiel für firstprivate Variable Transformierter Zugriff auf eine firstprivate Variable Zugriff auf gemeinsame Variable i Transformierter Zugriff auf eine gemeinsame Variable Einteilung des Iterationsraumes in Blöcke Gerüst einer statisch zugeteilten Schleife single Konstrukt vor der Transformation single Konstrukt nach der Transformation Aufbau der Regionenhierarchie Laufzeit zu Benchmark Raytracing Beschleunigung zu Benchmark Raytracing vii

14 Abbildungsverzeichnis 4.3 Ausschnitt des Matrix Summen Programmes Laufzeit zu Benchmark Matrix Summe Effizienz zu Benchmark Matrix Summe Laufzeit zu Benchmark Series Beschleunigung zu Benchmark Series Laufzeit zu Benchmark SparseMatrixMultiplication Beschleunigung zu Benchmark SparseMatrixMultiplication Direkte Übersetzung Übersetzung mit Vorübersetzer Beispielprogramm zum Entfernen eines Kontrollfadens viii

15 Tabellenverzeichnis 1.1 Überlick über die Typen von parallelen Systemen Variablenwerte zu Abbildung Vorbelegungen der Reduktionsoperationen Mögliche Kombinationen für eine Reduktion Messergebnisse zu Benchmark Raytracing Messergebnisse zu Benchmark Matrix Summe Messergebnisse zu Benchmark Series Messergebnisse zu Benchmark SparseMatrixMultiplication A.1 Kanonische Form der Schleife A.2 Ablauftypen des for Konstruktes A.3 Vorbelegung bei einer Reduktion A.4 Mögliche Kombinationen für eine Reduktion ix

16 Tabellenverzeichnis x

17 1. Einleitung 1.1. Hintergrund Trotz der rasanten Entwicklung von Rechnern in den letzten Jahrezehnten ist der Bedarf an leistungsfähigen Rechenanlagen ungebrochen und Großrechner sind gefragter denn je. Im letzten halben Jahr wurden zwei Rechner BlueGene/L am Department of Energy von IBM sowie das System Columbia der NASA von SGI [14] in Betrieb genommen, die beide den bisher schnellsten Rechner, den Earth Simulator von NEC am Earth Simulation Center in Yokohama, übertreffen. Neben den Hochleistungssystemen erfreuen sich aber auch kleinere, oft Linux basierte Rechnerbündel dank Systemen wie Beowulf [2] immer größerer Beliebtheit, da die Anschaffungskosten aufgrund der Verwendung von Standardkomponenten nur noch einen Bruchteil der Kosten früherer Hochleistungsrechner betragen. Allerdings ist die Programmierung von parallelen Systemen mit deutlich mehr Aufwand verbunden als die Entwicklung von Programmen für Einprozessorsysteme, da ein Entwickler sich selbst zusätzlich zur Implementation seines Programmes um dessen Parallelisierung kümmern muss. Da die Anwendungen, die auf diesen Systemen genutzt werden, oft aus dem wissenschaftlichen bzw. ingenieurtechnischen Bereich kommen, ist es wünschenswert, dass die Programmierung vom Wissenschaftler selbst durchgeführt werden kann und dabei möglichst wenig Zeit und Fachkenntnis für die Parallelisierung des Programmes aufgewendet werden muss. Eine Möglichkeit, die Entwicklung dabei zu unterstützen, ist OpenMP [20], ein Standard zur einfachen und flexiblen Parallelisierung sequentieller Programme. In dieser Arbeit soll der OpenMP Standard für das DSM System Jackal implementiert werden. Sie unterscheidet sich dabei von bisherigen OpenMP Implementationen dadurch, dass zum einen die OpenMP Spezifikation für die Sprache Java übernommen wird. Zum anderen handelt es sich bei JaMP um eine Umsetzung des OpenMP Standards für DSM Systeme, für welche die OpenMP Spezifikation ursprünglich nicht ausgelegt ist Überblick über parallele Systeme Diese Arbeit bewegt sich im Bereich der verteilten Systeme. Daher ist es hilfreich, zuerst einen Überblick über verschiedene Arten von parallelen Systemen zu geben. Diese lassen 1

18 1. Einleitung sich unter anderem nach der Art des Speicherzugriffes untergliedern. Tabelle 1.1 zeigt einen Überblick über die hier vorgestellten Systeme. Gemeinsamer Speicher (Shared Memory) Bei einem System mit gemeinsamem Speicher verfügen alle Rechner über einen gemeinsamen, einheitlichen Adressraum. Dies ist z.b. bei einem symmetrischen Mehrprozessorsystem (SMP) der Fall, bei dem ein Rechner über mehrere Prozessoren, aber nur über einen Arbeitsspeicher verfügt, der von allen Prozessoren gemeinsam genutzt wird. Da die für die Programmausführung nötigen Daten nur in einem Speicher vorhanden sind, müssen diese nicht zwischen den Programminstanzen abgeglichen werden. Die Programmierung eines Shared Memory Systems unterscheidet sich von der Programmierung eines Einprozessorsystems dadurch, dass der Programmierer diejenigen Abschnitte seines Quellprogrammes, die parallel ausgeführt werden sollen, mit mehreren Kontrollfäden ausführt und dabei selbst für die Erzeugung dieser Kontrollfäden sorgt. Dazu können spezielle Bibliotheken verwendet werden (siehe dazu Kapitel 5.1.1). Da kein Datenaustausch über ein Netzwerk stattfinden muss, sind die Latenzzeiten von Shared Memory Systemen gering. Im Vergleich zu anderen Systemen sind allerdings die maximale Anzahl von Prozessoren sowie die Speichergröße begrenzt. Verteilter Speicher (Distributed Memory) In Systemen mit verteiltem Speicher verfügt jeder Rechner über eigenen Speicher mit eigenem Adressraum, der aber von allen Rechnern genutzt wird. Gemeinsam genutzte Daten müssen dabei vom Programmierer an die einzelnen Programminstanzen zugewiesen und zwischen diesen abgeglichen werden, wozu es verschiedene Bibliotheken gibt (z.b. MPI [13]). Dies bedeutet aber einen wesentlichen Mehraufwand, da zusätzlich zur Erzeugung der Prozesse auch der Datenaustausch zwischen diesen implementiert werden muss. Prozesse können auf unterschiedlichen Rechnern laufen und jeweils aus mehreren Kontrollfäden bestehen. Die Größe des verwendbaren Arbeitsspeichers ist bei Distributed Memory Systemen um ein Vielfaches höher als bei Shared Memory Systemen. Jedoch ist auch die Latenzzeit beim Zugriff auf den Speicher wesentlich größer, da die Daten nicht über einen internen Systembus, sondern beispielsweise über ein wesentlich langsameres Netzwerk ausgetauscht werden müssen. Verteilter gemeinsamer Speicher (Distributed Shared Memory) Wie der Name schon andeutet, verbindet ein System mit verteiltem gemeinsamem Speicher (Distributed Shared Memory, DSM) die Vorteile der beiden vorher genannten Modelle. Durch eine zusätzliche Hardware oder Software Schicht (H DSM bzw. S DSM) wird der verteilte Speicher zu einem virtuellen gemeinsamen Speicher. Die Verteilung der Daten, die bei einem DSM System vorgenommen werden muss, geschieht automatisch und für den Programmierer transparent. Somit ist der Aufwand für die Programmierung in einem DSM System mit dem für ein Shared Memory System vergleichbar. Nahezu alle großen 2

19 1.3. Jackal Ein Distributed Shared Memory System Shared M. Distributed M. DSM Speichergröße gering hoch hoch Anzahl CPUs gering hoch hoch Zugriff sehr schnell langsam langsam Programmieraufwand mittel hoch mittel Tabelle 1.1.: Überlick über die Typen von parallelen Systemen. parallelen Systeme mit gemeinsamem Speicher und einer großen Anzahl von Prozessoren fallen in diese Kategorie Jackal Ein Distributed Shared Memory System Bei Jackal [26] handelt es sich um ein Übersetzersystem, das ein virtuelles DSM System durch eine zusätzliche Softwareschicht erzeugt. Als Knoten für dieses System können die Rechner eines beliebigen, vernetzten Rechnerbündels dienen. Jackal übersetzt Java Programme in Maschinenprogramme für verschiedene Architekturen, so z.b. für IA32, IA64, AMD64 oder PowerPC. Java Programme werden mit Hilfe der Java Threading API parallelisiert, indem die Programmabschnitte, die parallel ausgeführt werden sollen, in eine Klasse eingefügt werden, die von der Klasse java.lang.thread abgeleitet ist. Solche Java Programme können mit Jackal ohne Änderungen am Quellprogramm von einem Mehrprozessorsystem auf einen Rechnerbündel übernommen werden. Bei der Übersetzung werden in das Programm zusätzliche Befehlssequenzen, so genannte Access Checks, eingefügt, durch die bei jedem Zugriff auf gemeinsam genutzte Objekte sichergestellt wird, dass diese auf allen Knoten verfügbar sind, die darauf zugreifen [26]. Die Daten werden dabei automatisch auf dem gleichen Stand gehalten. Änderungen, die an einem Rechner vorgenommen werden, werden so an alle anderen Knoten weitergegeben und automatisch über das Netzwerk mit Hilfe einer Message Passing Bibliothek ausgetauscht (siehe dazu Kapitel 5.1.1). Neu angelegte Kontrollfäden werden automatisch auf dem Rechnerbündel verteilt, so dass alle vorhandenen Knoten in den Programmablauf einbezogen werden. Dazu wird beim Hinzufügen eines weiteren Kontrollfadens bestimmt, auf welchem Knoten dieser ausgeführt werden soll. Für den Programmierer geschieht dies vollkommen transparent und die Programme bleiben weiterhin Java konform. Eine Besonderheit von Jackal ist die Plattform Heterogenität, die es möglich macht, einen Rechnerbündel aus verschiedenen Knoten der unterstützten Architekturen als DSM System zu verwenden. 3

20 1. Einleitung 1 const int s i z e = 100; 2 3 int main ( ) { 4 int a r r = new int [ s i z e ] ; 5 int i = 0 ; int sum = 0 ; 6 7 // I n i t i a l i s i e r u n g 8 for ( int i = 0 ; i < s i z e ; i ++) a r r [ i ] = i ; 9 10 // Berechnung der Summe 11 #pragma omp parallel for shared ( a r r ) reduction (+:sum) 12 for ( i = 0 ; i < s i z e ; i ++) 13 sum += a r r [ i ] ; 14 } Abbildung 1.1.: Summe einer Reihnung in C++ mit OpenMP Parallelisierung OpenMP Es wäre wünschenswert, den Übersetzer die Parallelisierung des Programmes automatisch vornehmen zu lassen. Solche Übersetzer sind allerdings nur mit großem Aufwand zu realisieren [8], da erkannt werden muss, welche Abschnitte sich für eine parallele Ausführung eignen. Ein einfacherer Ansatz ist, den Programmierer diese parallelen Abschnitte markieren zu lassen. Eine Möglichkeit für diese halbautomatische Parallelisierung ist der Standard OpenMP. OpenMP [20] ist ein herstellerunabhängiger Standard, der aus einer Entwicklung von SGI hervorging und nun von einem Gremium weiterentwickelt wird. Es stellt den De facto Standard zur herstellerunabhängigen Parallelisierung von Programmen für parallele Systeme dar. Der OpenMP Standard beschreibt für die Sprachen C/C++ und Fortran Erweiterungen in Form von Metakommentaren, mit denen parallele Abschnitte markieren werden können und die es dem Übersetzer ermöglichen, eine Parallelisierung des Programmes vorzunehmen. Abbildung 1.1 zeigt ein einfaches C++ Programm, das die Summe einer Reihung errechnet. Durch den OpenMP Kommentar (Zeile 11) wird, wenn das Programm mit einem OpenMP fähigen Übersetzer kompiliert wird, automatisch eine parallele Version erzeugt, deren Ausführung unter Verwendung mehrerer Kontrollfäden abläuft. 4

21 1.5. JaMP 1.5. JaMP Auch wenn die OpenMP Spezifikation DSM Systeme nicht berücksichtigt, so ist Open- MP doch eine realisierbare Erweiterung für Jackal. So wie Jackal dem Programmierer die Daten und Prozessverteilung abnimmt, so ermöglicht OpenMP eine halbautomatische Parallelisierung des Programmes. Aus diesem Grund ist es Ziel dieser Arbeit, eine an Jackal angepasste OpenMP Version, JaMP, zu implementieren. JaMP soll es ermöglichen, Programme schneller und einfacher zu parallelisieren. Dazu soll es möglich sein, einzelne Abschnitte des Programmes von mehreren Kontrollfäden parallel ausführen zu lassen. In dem parallelen Programmteil wird auf Variablen zugegriffen, die vor diesem definiert wurden. Für diese Variablen soll festgelegt werden können, welche von allen Kontrollfäden gemeinsam genutzt werden und für welche für jeden Kontrollfaden eine eigene Kopie angelegt wird. Bei Schleifen sollte jeder Iterationsschritt nur einmal ausgeführt werden. Der Iterationsraum der gesamten Schleife muss dazu auf die laufenden Kontrollfäden aufgeteilt werden. Bei anderen Abschnitten kann es nötig sein, deren Ausführung auf einzelne Kontrollfäden zu beschränken (z.b. Bildschirmausgaben). Weiterhin sind zur Ablaufsteuerung Barrieren und kritische Abschnitte nötig, die nur von einem Kontrollfaden gleichzeitig betreten werden können (z.b. Dateisystemzugriff) Gliederung Nach dieser Einführung wird in Kapitel 2 auf JaMP als Implementierung eines OpenMP Dialektes im Software DSM System Jackal eingegangen und ein Überblick über dessen Funktionalität gegeben. Weiterhin werden die Unterschiede dieser Implementierung zum OpenMP Standard aufgezeigt. Kapitel 3 thematisiert Implementationsdetails und führt genauer in die bei der Umsetzung verwendeten Konzepte und Methoden ein. In Kapitel 4 folgt eine Betrachtung der Leistungsfähigkeit von JaMP in Form von Benchmarks, mit denen die Geschwindigkeit von JaMP untersucht und im Vergleich zu anderen Parallelisierungsmethoden betrachtet werden soll. Kapitel 5 gibt schließlich einen Überblick über verwandte Arbeiten und gibt einen Ausblick darüber, welche Folgearbeiten im Zusammenhang mit dieser Arbeit möglich sind. Im Anhang findet sich abschließend eine Referenz aller JaMP Konstrukte sowie eine Liste der Unterschiede zwischen der Implementierung von JaMP und der OpenMP Spezifikation. 5

22 1. Einleitung 6

23 2. JaMP OpenMP für Jackal Mit JaMP soll es möglich sein, Java Programme mit wenig Aufwand zu parallelisieren. Die an einem Programm nötigen Anpassungen sollen möglichst gering ausfallen und es soll auch nach der Modifikation des Programmes weiterhin möglich sein, dieses mit einem Java Übersetzer, der über keine JaMP Unterstützung verfügt, übersetzen zu lassen. So kann eine serielle Version des Programmes entwickelt werden; zu diesem Programm können Markierungen hinzugefügt werden, die einen JaMP fähigen Übersetzer veranlassen, das Programm in eine parallele Version zu transformieren. Im folgenden werden Programme, die JaMP Direktiven enthalten, als JaMP Programme bezeichnet. Um JaMP Programme mit Jackal zu übersetzen, muss der Kommandozeilenparameter -jamp angegeben werden. Dieses Kapitel soll eine Einführung und einen Überblick über JaMP und dessen Funktionalität geben. Eine vollständige Referenz aller Konstrukte, Direktiven und Attribute findet sich in Anhang A. Auch das Laufzeitsystem, welches weitergehende Unterstützung und Schnittstellen für ein JaMP Programm zur Verfügung stellt, ist in Anhang A dokumentiert Kennzeichnung von Abschnitten Wie bereits in der Einleitung beschrieben, ist OpenMP [20] für C/C++ und Fortran spezifiziert. Bei Jackal handelt es sich jedoch um einen Übersetzer für Java Programme. Da die Unterschiede zwischen Java und C++ im Bezug auf eine mögliche OpenMP Implementierung gering sind, lehnt sich die Implementierung von JaMP an Version 2.0 der OpenMP Spezifikation für C/C++ an. Unterschiede, die zum Teil auf die Verwendung von Java anstelle von C++, aber auch auf den engen Rahmen dieser Arbeit zurückzuführen sind, werden im Abschnitt Unterschiede zu OpenMP am Ende dieses Kapitels beschrieben. In C++ können mit dem Pragma Mechanismus Metakommentare in ein Programm eingefügt werden. Diese Kennzeichnungen werden von einem OpenMP fähigen Übersetzer erkannt und das Programm wird entsprechend transformiert. Da Java über keinen solchen Pragma Mechanismus verfügt und da die Java Konformität von JaMP Programmen auch weiterhin gewährleistet werden soll, haben Pragmas in Jackal die Form von speziell gekennzeichneten Kommentaren: //#pragma <Kennzeichnung=jamp> <Konstruktname> <Attribute> 7

24 2. JaMP OpenMP für Jackal 1 public c l a s s Test { 2 public void foo ( ) { 3 // Java Programm 4 //#pragma jamp <Konstruktname> <Attribute > 5 { 6 // Dieser A b s c h n i t t s o l l von 7 // JaMP m o d i f i z i e r t werden... 8 } 9 // Java Programm 10 } 11 } Abbildung 2.1.: Gerüst eines JaMP Progammes. Auf die Pragma Deklaration folgt eine Kennzeichnung, um verschiedene Pragma Typen voneinander unterscheiden und in einem Programm verwenden zu können. Pragmas werden in Jackal beispielsweise auch für das Zusammenfügen von Objekten [27] genutzt. Für JaMP Pragmas wird die Kennzeichnung jamp verwendet. Der Konstruktname dient zur Unterscheidung verschiedener JaMP Konstrukte bzw. Direktiven. Als Konstrukt werden dabei Blöcke bezeichnet, die sich auf eine Reihe von Programminstruktionen beziehen. Konstrukte benötigen einen zugehörigen Java Block, der durch geschweifte Klammern ({ und }) gekennzeichnet ist. Ohne diese Klammerung ist es in Jackal nicht möglich, die einzelnen Instruktionen der Zwischensprache einer Java Anweisung zuzuordnen. Dieser Block muss direkt auf die Konstruktdeklaration folgen. Auch wenn ein Block nur aus einer einzigen Instruktion besteht, muss dieser mit Klammern umgeben werden. Pragma Anweisungen, die keinen Programmabschnitt zugeordnet haben, werden als Direktiven bezeichnet. Auf den Konstruktnamen können Attribute folgen, deren Werte an das Konstrukt übergeben werden. Konstrukte und Direktiven sind nur innerhalb von Methoden erlaubt. Abbildung 2.1 zeigt das Grundgerüst eines parallelen Abschnitts in einem JaMP Programm. Die Methode mit dem Namen foo() innerhalb der Klasse Test enthält einen Abschnitt, der von JaMP transformiert werden soll. Dazu wird dieser Programmteil mit dem gewünschten Konstrukt umgeben. Bei den folgenden Beispielen wird aus Platzgründen auf die Angabe von Klassen sowie Methodendeklarationen verzichtet Parallele Abschnitte Eine wichtige Aufgabe von JaMP ist es, einen Abschnitt eines Programmes parallel auszuführen. Parallel bedeutet hierbei, dass diese Abschnitt nicht nur mit einem Kontrollfaden, sondern mit einer ganzen Gruppe von Kontrollfäden ausgeführt wird. Um 8

25 2.2. Parallele Abschnitte //#pragma jamp parallel 3 { 4 System. out. p r i n t l n ( Hallo Welt ) ; 5 } 6... Abbildung 2.2.: Das Konstrukt parallel. JaMP mitzuteilen, dass ein Abschnitt parallel ausgeführt werden soll, wird dieser mit einem parallel Konstrukt umgeben. Ein Beispiel hierzu zeigt Abbildung 2.2. Wie Abbildung 2.3 schematisch zeigt, wird dabei der Teil des Programmes, der sich innerhalb des Konstruktes befindet, von jedem der erzeugten Kontrollfäden ausgeführt. Wird dieses Programm mit JaMP Untertützung übersetzt und ausgeführt, so wird in diesem Beispiel der Text Hallo Welt nicht nur einmal, sondern jeweils einmal von jedem Kontrollfaden aus der Gruppe am Bildschirm ausgegeben. Der auf den parallelen Abschnitt folgende Programmteil wird wiederum von nur einem Kontrollfaden ausgeführt. Während der Ausführung des parallelen Abschnitts wartet der Kontrollfaden, von dem aus die Gruppe generiert wurde, darauf, dass die erzeugten Kontrollfäden jeweils mit der Ausführung des Programmabschnitts fertig sind und fährt dann erst mit der Ausführung fort. Dieser Kontrollfaden ist in der Abbildung als gestrichelte Linie dargestellt. Jedem Kontrollfaden wird eine eindeutige, bei 0 beginnende Nummer zugewiesen. Dabei wird der Kontrollfaden mit der Nummer 0 als Hauptkontrollfaden bezeichnet, was in der Abbildung durch den etwas kräftigeren Pfeil auf der linken Seite dargestellt ist. Einige Aufgaben, die nur einmal ausgeführt werden dürfen, werden von diesem Kontrollfaden durchgeführt, beispielsweise die Wiederherstellung von gemeinsamen Variablen nach dem Verlassen einer parallelen Region oder Reduktionen. Es gibt verschiedene Möglichkeiten, die Anzahl der für eine Gruppe erzeugten Kontrollfäden zu beeinflussen. Zuerst steht hierzu das Attribut num_threads zur Verfügung, mit dem die Anzahl der Kontrollfäden direkt im Quellprogramm angegeben werden kann (Abbildung 2.4). Der Abschnitt, der sich in der parallel Umgebung befindet, wird in diesem Beispiel von fünf Kontrollfäden ausgeführt. Der Wert des num_threads Attributs kann entweder eine Ganzzahl oder eine Variable vom Typ int sein. Eine weitere Möglichkeit, die Anzahl der Kontrollfäden festzulegen, bietet das Laufzeitsystem über die Methode setnumthreads() (Anhang A.5.1). Außerdem wird die Eigenschaft JAMP_NUM_THREADS des Java Systems ausgewertet, die beim Start des Programmes über den Kommandozeilenparameter -DJAMP_NUM_THREADS=<...> übergeben werden kann. Dabei wird dem num_threads Attribut vor den anderen Möglichkeiten und der Methode setnumthreads() gegenüber dem Parameter JAMP_NUM_THREADS der Vorzug gegeben. 9

26 2. JaMP OpenMP für Jackal Abbildung 2.3.: Schematische Darstellung von parallelen Abschnitten //#pragma jamp parallel num threads(5) 3 { 4 System. out. p r i n t l n ( Hallo Welt ) ; 5 } 6... Abbildung 2.4.: Das Attribut num threads. 10

27 2.3. Zuweisung von Daten int a ; int b ; int c ; //#pragma jamp parallel private ( a, b ) shared ( c ) 5 { 6 a = 5 ; // Zuweisung an p r i v a t e Variable 7 b = 5 ; // Zuweisung an gemeinsame Variable 8 } 9... Abbildung 2.5.: Die Attribute private und shared. Wurde die Anzahl der Kontrollfäden mit keiner der hier genannten Möglichkeiten angegeben, so werden standardmäßig zehn Kontrollfäden erzeugt. Es ist möglich, verschachtelte parallele Regionen zu verwenden, also parallele Regionen, die im lexikalischen Bereich einer anderen parallelen Region enthalten sind. Das Standardverhalten ist, dass eine innere Region mit nur einem Kontrollfaden ausgeführt wird, da sich die Anzahl der laufenden Kontrollfäden sonst sehr schnell vergrößern kann. Dieses Verhalten kann durch die Methode setnested() im Laufzeitsystem (Anhang A.5.9) beeinflusst werden. Wird dieser Wert auf true gesetzt, so wird eine innere Region ebenfalls mit der angegebenen Anzahl von Kontrollfäden ausgeführt. Hierbei ist zu beachten, dass die Anzahl der laufenden Kontrollfäden sehr schnell ansteigen kann, wobei die maximale Anzahl an Kontrollfäden vom verwendeten Betriebssystem abhängt. Ausnahmen, die innerhalb der parallelen Region entstehen, müssen auch in dieser behandelt werden. Andernfalls wird das laufende Programm vom JaMP Laufzeitsystem beendet. Die Verwendung von Befehlen zur Kontrollfadensteuerung, wie wait() oder notifyall(), ist nicht erlaubt Zuweisung von Daten In parallelen Abschnitten muss es möglich sein, jedem Kontrollfaden entweder eine eigene Kopie einer Variablen zuweisen zu können oder alle Kontrollfäden auf eine gemeinsame Speicherstelle zugreifen zu lassen. Da Veränderungen an gemeinsamen Variablen in einem DSM System an alle Knoten weitergereicht werden müssen, ist die Latenz beim schreibenden Zugriff auf gemeinsame Daten hoch. Wenn es der Algorithmus erlaubt, sollte aus diesem Grund versucht werden, möglichst viele Variablen privat zu halten. Dazu werden die Variablen über Attribute im Pragma Kommentar entsprechend gekennzeichnet. Private Variablen werden mit den Attributen private oder firstprivate versehen, gemeinsame Variablen mit dem Attribut shared. Jedem dieser Attribute kann eine durch Kommata getrennte Liste von Variablen übergeben werden. Ein Beispiel hierzu zeigt 11

28 2. JaMP OpenMP für Jackal Abbildung 2.6.: Private und gemeinsame Variablen. Abbildung 2.5. Bei privaten Variablen ist ein Speicherplatz für jeden Kontrollfaden reserviert, bei gemeinsamen Variablen ein einziger Speicherplatz für alle Kontrollfäden. Dies verdeutlicht Abbildung 2.6. Wenn von einer gemeinsamen Speicherstelle von shared Variablen die Rede ist, so wird nur dann wirklich die selbe Speicherstelle verwendet, wenn das Programm auf einem Shared Memory System läuft. Ein DSM System dagegen sorgt automatisch und für den Nutzer transparent für einen Abgleich der Daten zwischen den einzelnen Knoten, so dass der Eindruck einer gemeinsamen Speicherstelle entsteht. Aus diesem Grund soll diese Bezeichnung auch für DSM Systeme verwendet werden. Private Variablen (private) Private Variablen verfügen in jedem Kontrollfaden über einen eigenen Speicherplatz. Bei primitiven Datentypen (int, double, usw.) wird dieser Speicherplatz nicht initialisiert, bei Objekten wird er mit dem Standardwert vorbelegt, der sich durch das Anlegen eines neuen Objektes und die Ausführung von dessen Standardkonstruktor ergibt. Ist kein Standardkonstruktor vorhanden, so kann ein Objekt nicht als private Variable verwendet werden. In diesem Fall kommt es zu einem Laufzeitfehler, da zur Übersetzungszeit nicht festgestellt werden kann, ob ein entsprechender Konstruktor vorhanden ist, da Jackal keine Möglichkeit zum Auslesen von Informationen über Konstruktoren zur Übersetzungszeit zur Verfügung stellt. Reihungen werden mit einer neu angelegten Reihung der gleichen Größe initialisiert, wobei die Werte der einzelnen Elemente nicht vorbelegt werden. Privat mit Vorbelegung (firstprivate) Soll für eine private Variable der Wert der Variablen aus der umgebenden Region bzw. der Wert vor der parallelen Region übernommen werden, so kann eine Variable als firstprivate deklariert werden. Bei primitiven Datentypen wird der Wert der Variable 12

29 2.3. Zuweisung von Daten in den neuen Speicherplatz kopiert, bei Objekten wird durch den Aufruf der clone() Methode eine Kopie erstellt. Dies setzt voraus, dass die Schnittstelle Cloneable implementiert wird. Ist dies nicht der Fall, so kann ein Objekt nicht als firstprivate Variable genutzt werden. Wie bei privaten Variablen kommt es in diesem Fall zu einem Laufzeitfehler. Reihungen können als firstprivate Variablen nicht verwendet werden und führen ebenfalls zu einem Laufzeitfehler. Gemeinsame Variablen (shared) Sollen alle Kontrollfäden auf eine gemeinsame Speicherstelle zugreifen, so kann die Variable als shared deklariert werden. Die Daten werden hierzu in einem für alle Kontrollfäden sichtbaren Speicherbereich abgelegt und nach der Ausführung der parallelen Region wieder an den ursprünglichen Speicherplatz zurückkopiert. Gemeinsame Variablen können nur an einem parallel Konstrukt deklariert werden. Ist der Typ einer Variablen nicht spezifiziert, so wird sie als gemeinsame Variable angesehen. Dieses Verhalten kann mit dem Attribut default (Anhang A.4.1) geändert werden. Die Variable this wird gesondert behandelt und dem parallelen Abschnitt direkt als Parameter übergeben, so dass ein Zugriff auf diese Variable nicht über das JampParam Objekt erfolgen muss. Es ist möglich, Variablen in verschachtelten Regionen mehrfach als privat zu deklarieren. So ist es z.b. möglich, eine Variable im parallel Konstrukt als gemeinsam und in einer darin enthaltenen anderen Region als privat zu deklarieren. Dies wird als Reprivatisierung bezeichnet. In diesem Fall wird für die Variable in der inneren Region ein neuer Speicherplatz reserviert. Abbildung 2.7 zeigt zur besseren Verdeutlichung hierzu ein weiteres Beispiel. Die Variablen a, b und c werden in einem parallelen Abschnitt jeweils um eins erhöht. Betrachten wir zunächst die Ausführung bis zu Zeile 10, in der die Variablen verändert werden. In Tabelle 2.1(a) befindet sich in jeder Spalte die Bildschirmausgabe eines Kontrollfadens. Da Variable a als private deklariert ist, ist ihr Anfangswert undefiniert und wird in diesem Beispiel mit 0 angenommen. Variable b erhält wie Variable a einen eigenen Speicherplatz, der mit dem Wert vorbelegt wird, den b vor der parallelen Region hatte, in diesem Fall mit dem Wert 2. Variable c wird auch aus dem umgebenden Bereich übernommen und hat somit in allen Kontrollfäden den Wert 3. Die Werte der Variablen nach deren Veränderung in Zeile 10 ist in Tabelle 2.1(b) zu sehen. Die Variablen a und b haben einen jeweils um eins höheren Wert als vor der Veränderung. Bei der Modifikation der Variablen c wird von allen Kontrollfäden jeweils auf den gleichen Speicherplatz zugegriffen und somit jeweils ein anderes Ergebnis erzielt. Dabei ist zu beachten, dass der Zugriff auf gemeinsame Variablen synchronisiert erfolgen sollte. Der Übersicht halber wurde dies in diesem Beispiel weggelassen. Die hierzu benötigten Methoden werden später in diesem Kapitel vorgestellt. Am Ende wird der gemeinsame Wert der Variablen c wieder an die ursprüngliche Speicherstelle kopiert, die neuen Werte von a und b werden verworfen. 13

30 2. JaMP OpenMP für Jackal int a = 1 ; int b = 2 ; int c = 3 ; 3 4 //#pragma jamp parallel num threads ( 3 ) \ 5 private ( a ) firstprivate ( b ) shared ( c ) 6 { 7 p r i n t ( a : + a ) ; 8 p r i n t ( b: + b ) ; 9 p r i n t ( c : + c ) ; 10 a++; b++; c++; 11 p r i n t ( a : + a ) ; 12 p r i n t ( b: + b ) ; 13 p r i n t ( c : + c ) ; 14 } Abbildung 2.7.: Beispiel für private, firstprivate und shared. Thr. 1 Thr. 2 Thr. 3 a: 0 a: 0 a: 0 b: 2 b: 2 b: 2 c: 3 c: 3 c: 3 (a) Vor der Änderung. Thr. 1 Thr. 2 Thr. 3 a: 1 a: 1 a: 1 b: 3 b: 3 b: 3 c: 4 c: 6 c: 5 (b) Nach der Änderung. Tabelle 2.1.: Variablenwerte zu Abbildung 2.7. Am Ende fast aller Konstrukte (siehe dazu Anhang A) befindet sich eine implizite Barriere, an der die Kontrollfäden warten, bis alle Mitglieder der Gruppe die Ausführung des Abschnitts beendet haben. Mit dem Attribut nowait kann diese Barriere deaktiviert werden. In diesem Fall fährt ein Kontrollfaden mit der Ausführung fort, ohne auf die anderen Mitglieder der Gruppe zu warten Schleifen Wenn ein Programmabschnitt von mehreren Kontrollfäden parallel ausgeführt wird und jede Instruktion somit mehrfach ausgeführt wird, so ist es bei Schleifen wünschenswert, dass jede Iteration der Schleife nur einmal bearbeitet wird. Der Arbeitsbereich einer Schleife soll also auf die Kontrollfäden aufgeteilt werden. Dazu muss die Anzahl der Iterationen vor dem Betreten der Schleife berechnet werden. Damit dies möglich ist, wurden 14

31 2.4. Schleifen //#pragma jamp parallel 3 { 4 //#pragma jamp for 5 for ( < I n i t i a l i s i e r u n g >; <Bedingung >; <Inkrement > ) { 6 //... Berechnung 7 } 8 } 9... Abbildung 2.8.: Deklaration eines for Konstruktes. die im Schleifenkopf erlaubten Ausdrücke und Operationen zu einer kanonischen Form eingeschränkt (Abbildung 2.8). Dabei ist die Schleifeninvarianz dieser Ausdrücke eine Bedingung für die Vorbestimmung des Iterationsraumes einer Schleife. Bei verschachtelten Schleifen wird nur diejenige, die direkt auf das for Konstrukt folgt, transformiert, alle anderen werden nicht verändert. Initialisierung Die Initialisierung besteht aus einer einfachen Zuweisung zu einer Variablen vom Typ int, die auch erst an dieser Stelle deklariert werden darf. Sie hat also entweder die Form <Variable> = <Wert> oder int <Variable> = <Wert>. Andere Datentypen werden nicht unterstützt, wobei eine Unterstützung des Typs long möglich wäre, aber aus Zeitgründen nicht implementiert wurde. Die hier verwendete Variable ist automatisch privat und darf, abgesehen von einer Reduktion und dem Typ lastprivate, in keinem Attribut dieses Konstruktes vorkommen. Die selbe Variable muss auch im Bedingungs und im Inkrement Teil des Schleifenkopfes verwendet werden. Damit die Iterationszahl vor dem Schleifendurchlauf bestimmt werden kann, darf weiterhin die in der Initialisierung verwendete Variable im Schleifenrumpf nicht modifiziert werden. Bedingung In der Bedingung muss die in der Initialisierung verwendete Variable mit einem schleifeninvarianten Ausdruck verglichen werden: <Variable> <Operator> <schleifeninvarianter Ausdruck> Als Operatoren stehen <, <=, > und >= mit der üblichen Semantik zur Verfügung, andere Vergleiche sind nicht erlaubt. Der Ausdruck kann entweder ein konstanter ganzzahliger Wert oder eine Variable vom Typ int sein. Komplexere Ausdrücke können 15

32 2. JaMP OpenMP für Jackal verwendet werden, indem diese vor der Schleife in eine temporäre Variable geschrieben werden, die dann als schleifeninvarianter Ausdruck verwendet wird. Inkrement Die in der Initialisierung verwendete Variable wird im Inkrement Ausdruck entweder um einen konstanten Ganzzahlwert oder um eine schleifeninvariante Variable vom Typ int erhöht oder erniedrigt. Es stehen also nur die Operationen + und - zur Verfügung. Steht die Anzahl der Schleifeniterationen fest, so können diese vor dem Betreten der Schleife auf die laufenden Kontrollfäden verteilt werden. Hierzu stehen verschiedene Ablauftypen zur Verfügung, die über das Attribut schedule ausgewählt werden können: //#pragma for schedule(<typ>[, <Blockgröße>]) Der angegebene Typ kann dabei den Wert static, dynamic oder guided haben. Unter einem Berechnungsblock, im folgenden nur Block genannt, versteht man einen zusammenhängenden Abschnitt des Iterationsraumes. Die Bedeutung des optionalen Wertes Blockgröße hängt vom verwendeten Typ ab, gibt aber in der Regel an, wie viele Iterationen zu einem Block zusammengefasst werden. Ist kein Typ angegeben, so wird eine statische Ablaufzuteilung verwendet. Statisch (static) Wird eine statische Ablaufplanung gewählt, so werden die Iterationen vor der Ausführung der Schleife fest den Kontrollfäden der Gruppe zugeteilt. Ist eine Blockgröße angegeben, so werden die Blöcke im so genannten Round Robin Verfahren aufgeteilt. Dabei bekommt jeder Kontrollfaden der Reihe nach einen Block, bis alle verteilt sind. Ist keine Blockgröße angegeben, so wird der Iterationsraum in gleich große Teile aufgeteilt, so dass jeder Kontrollfaden genau einen Block erhält. Lassen sich die Blöcke nicht genau auf die Kontrollfäden aufteilen, so erhält der letzte Kontrollfaden einen kleineren Block als die anderen. Dynamisch (dynamic) Bei der dynamischen Ablaufzuteilung wird der Iterationsraum in Blöcke der angegebenen Größe aufgeteilt. Hat ein Kontrollfaden die Bearbeitung des ihm zugeteilten Blocks beendet, so nimmt er sich den nächsten nicht bearbeiteten Block aus der Liste der noch unbearbeiteten Blöcke. Dies geschieht solange, bis der ganze Iterationsraum vollständig abgearbeitet wurde. Ist keine Blockgröße angegeben, so werden Blöcke der Größe eins erzeugt. 16

33 2.5. Reduktionen Geführt (guided) Diese Methode ähnelt der dynamischen Blockzuteilung, wobei jedoch die Größe der Blöcke von Iteration zu Iteration kleiner wird. Die Größe des ersten Blocks ist ein Drittel der Iterationszahl und sie halbiert sich jeweils im Vergleich zu der des vorhergehenden Blocks, wobei die angegebene Blockgröße als untere Schranke dient. Diese Art von Ablaufzuteilung bietet sich vor allem für Algorithmen an, deren Berechnungszeit pro Iterationselement mit zunehmender Iterationszahl deutlich steigt (z.b. Primzahlberechnung). Bei Schleifen steht zusätzlich zu private und firstprivate ein weiterer Variablentyp zur Verfügung: lastprivate. Ist eine Variable mit diesem Typ gekennzeichnet, so wird der Wert aus dem letzten Iterationsschritt in die gleichnamige Variable des umgebenden Konstruktes bzw. an den ursprünglichen Speicherplatz außerhalb der parallelen Region kopiert. So kann beispielsweise der letzte Wert der Zählvariablen der Schleife auch nach der Schleife noch verwendet werden Reduktionen Will man beispielsweise die Summe über eine Reihung bilden, so benötigt man eine gemeinsame Variable zur Aufsummierung des Ergebniswertes. In jeder Iteration liest jeweils ein Kontrollfaden den gemeinsamen Wert, verändert ihn und schreibt das Ergebnis wieder in die gemeinsame Variable zurück. Damit das Ergebnis korrekt ist, muss der Zugriff auf diese Variable synchronisiert geschehen, was die Berechnung verlangsamt. Eine bessere Lösung ist, die Teilsummen, die jeder Kontrollfaden berechnet, in eine private Variable zu schreiben und diese Teilergebnisse am Ende zusammenzufassen. Dieses Verfahren wird als Reduktion bezeichnet. Um eine Variable zu reduzieren, wird diese im Attribut reduction zusammen mit einer assoziativen Operation aufgeführt:...reduction(<operation>:<liste von Variablen>)... Tabelle 2.2 zeigt alle möglichen Operationen, deren Initialisierungswerte sowie deren semantische Bedeutung. Eine in einer Reduktion verwendete Variable ist automatisch privat. Allerdings ist deren Wert nicht undefiniert, sondern wird mit dem neutralen Element der gewählten Operation initialisiert. Eine Reduktion ist nur mit Variablen möglich, die einen primitiven Datentyp besitzen. Die möglichen Operationen hängen vom Datentyp ab, da nicht mit jedem Datentyp jede Operation möglich ist. Da in Java Operationen mit short und byte Variablen ein Ergebnis vom Typ int zurückliefern, ist mit ihnen keine Reduktion möglich. Alle gültigen Kombinationen aus Datentypen und Operationen zeigt Tabelle 2.3. Nachdem eine Region von allen Kontrollfäden abgearbeitet wurde und die Teilergebnisse in den jeweiligen privaten Variablen stehen, werden diese mit der angegebenen Operation zusammengefasst (Abbildung 2.9). Wird beispielsweise die Operation + 17