OpenMP-Aktivitäten im Rechen- und Kommunikationszentrum der RWTH Aachen

Transkript

1 OpenMP-Aktivitäten im Rechen- und Kommunikationszentrum der RWTH Aachen Dieter an Mey Rechen- und Kommunikationszentrum, RWTH Aachen Universität, Aachen, Deutschland 1 Historie Hochleistungsrechnen an der RWTH bedeutete in der Vergangenheit Vektorisierung. Der für die 80-er Jahre gute Zugang zum Bochumer Landesvektorrechner CDC Cyber 205 war der Ausgangspunkt für Softwareentwicklungen, die die Vektorrechnerarchitektur schon bei der Konzeption der Simulationsprogramme berücksichtigten. Als Konsequenz wurden in den 90-er Jahren Vektorrechner und Parallelvektorrechner der Firma Siemens/Fujitsu an der RWTH Aachen betrieben und auch der Universalrechner dieser Zeit, ein 6-Prozessor IBM 3090 Shared-Memory-Rechner, war mit Vektoreinheiten bestückt. Als dann Ende der 90-ziger die Standardmikroprozessoren ein deutlich günstigeres Preis- Leistungsverhältnis entwickelten, wurde das derzeitige Sun Fire SMP-Cluster als Universal- und Hochleistungsrechner bereitgestellt. 2 OpenMP - die Anfänge Der Zusammenschluss von SGI und Cray gab die Initialzündung zur Entwicklung der ersten OpenMP-Spezifikation für Fortran 1997 und für C/C wurde im Rahmen der Evaluationsphase für den nachfolgenden Hochleistungsrechner eine HP V-Class Maschine beschafft, deren 16 Prozessoren auf einen gemeinsamen flachen Speicher zugreifen konnten, sowie der damals bekannteste OpenMP-Compiler Guide, als Teil des KAP/Pro-Toolsets von KAI. Eine weitere Komponente dieser Software-Suite war Assure, ein zum damaligen Zeitpunkt einzigartiges Hilfsmittel zur Verifikation von OpenMP-Programmen (es wurde inzwischen durch den Intel ThreadChecker abgelöst). Der erste Schritt bestand darin, die bestehenden Vektorprogramme in OpenMP-Programme umzuwandeln. Dazu wurde verschiedene automatisch parallelisierende Compiler evaluiert und auch der Präprozessor Visual KAP for OpenMP ebenfalls von KAI, mit dem man automatisch OpenMP-Direktiven für ein Fortran90-Programm generieren konnte - allerdings leider nur unter dem Betriebssystem Windows NT. Letztendlich wurden diese Möglichkeiten von Fall zu Fall kombiniert, automatische Parallelisierung durch Compiler, automatische Generierung von OpenMP

2 Direktiven mit Visual KAP, manuelles Einfügen von OpenMP Direktiven und deren Korrektheitsprüfung mit Assure. [1,2] Auch standen und stehen einige Shared-Memory-parallele Bibliotheken zur Verfügung, wie die NAG SMP Library und die Sun Performance Library. So wurden z. B. im Zuge der engen Zusammenarbeit mit der Firma Sun Microsystems spezielle Routinen zur 3D-FFT parallelisiert, die dann recht erfolgreich in Kombination mit automatischer und manueller OpenMP Parallelisierung für das Program DNS des Instituts für Technische Verbrennung der RWTH Aachen eingesetzt werden konnte (DNS=Direct Numerical Simulation for turbulent flows, speedup=10 mit 16 Threads auf einer SunFire E6900). [3] Schon frühzeitig wurde eine wichtige Möglichkeit erkannt, das manuelle Parallelisieren von Schleifen zu erleichtern: OpenMP-Compiler verfügen in der Regel auch über Möglichkeiten der automatischen Parallelisierung und damit über eine ausgefeilte Datenabhängigkeitsanalyse. Warum sollte diese Analysefähigkeit der Compiler nicht in den Dienst der OpenMP-Programmierer gestellt werden können? Auf einen Vorschlag hin war die Firma Sun Microsystems bereit, eine dahingehende Compiler-Erweiterung zu implementieren, das so genannte Autoscoping, das inzwischen fester Bestandteil aller Sun Compiler geworden ist, aber noch nicht in den OpenMP Sprachumfang aufgenommen wurde. Am Panta-Code zur Simulation von Gasturbinen des Institutes für Strahlantriebe und Turboarbeitsmaschinen der RWTH erzeugte Autoscoping automatisch korrekte OpenMP Deklarationen für über 1300 Variablen, nur 13 mussten vom Programmierer von Hand noch deklariert werden, ohne Autoscoping hätte der Programmierer all diese 1300 Variablen manuell deklarieren müssen. [4,1] 3 Skalierbarkeit Wie kann man nun die Skalierbarkeit von OpenMP-Programmen verbessern? Mitunter sind die seriellen Anteile von Simulationsprogrammen nach einer gründlichen Schleifenparallelisierung nicht mehr groß, aber der Overhead der OpenMP- Laufzeitbibliothek behindert die Skalierbarkeit. Abhilfe kann hier das Ausdehnen der Parallelen Regionen schaffen, so dass diese nicht mehr nur eine parallele Schleife beinhalten, sondern mehrere und falls möglich sogar alle! [20, 21,18] Dieser Ansatz wurde konsequent im Rahmen eines Projektes mit dem Thermoflow Code für Triebwerkssimulation des Institutes für Strahlantriebe durchgeführt, [5] was zu einem beachtlichen Erfolge führte: Auf der 72-Prozessor Sun Fire 15K wurde ein Speed-up von 40 erreicht mit 64 Threads, obwohl sich die Parallelisierung nur auf die inneren Schleifen beschränkte! Eine einzige Parallele Region umschloß den gesamten rechenintensiven Programmteil. Darüber hinaus wurden das Schleifen-Scheduling, also die Verteilung der Arbeit auf die einzelnen Threads für jeden vorkommenden Schleifentyp, vorausberechnet und dann immer wieder verwendet. [6] Ein anderes Handicap haben die ccnuma-architekturen. Während das Betriebssystem Solaris 8 die Architektur der Sun Fire 15K diesbezüglich ignorierte und

3 die Daten quasi-zufällig über alle 18-Prozessorboards verteilte und damit dem Programmierer den Eindruck von einem zwar langsamen aber flachen Speicher vermittelte, setzte Solaris 9 (ab Update 1) die neue Memory Placement Optimization (MPO) Komponente ein. Dabei wurde plötzlich die First-Touch-Strategie verwendet, welche Daten auf dem Speicher des Prozessors platziert, der als erster diese Daten liest, so dass die Skalierbarkeit dieses ThermoFlow-Programms deutlich litt. Daten, die anfangs vom Master-Thread gelesen und initialisiert werden, liegen daher alle auf dem Board des Master-Threads und in der Parallelen Region müssen dann alle Threads über die Backplane auf den Speicher dieses Boards zugreifen, was bei einer hohen Anzahl von Threads zu einem deutlichen Engpass führt. Gezieltes paralleles Initialisieren konnte Abhilfe schaffen, ergab aber in diesem Fall keine weitere Beschleunigung über die anfänglich unter Solaris 8 gemessenen Rechengeschwindigkeiten, da die meisten Daten in diesem FEM-Programm alternierend konsekutiv und indirekt adressiert werden. Solaris bietet gut nutzbare Hilfsmittel zum Umgang mit ccnuma-architekturen an, die aber leider nicht portierbar sind. In vielen Fällen kann damit die Skalierbarkeit deutlich verbessert werden. 4 C++ und OpenMP Während bislang Fortran-Programme eindeutig die meiste Rechenzeit auf den Aachener Hochleistungsrechnern in Anspruch nehmen, deuten aktuelle Entwicklungen darauf hin, dass sich diese Situation in Zukunft möglicherweise ändern wird. Die deutlich höhere Ausdrucksfähigkeit und Abstraktionsfähigkeit von C++ im Vergleich zu Fortran hat dazu geführt, dass insbesondere Numeriker und Informatiker sich von Fortran abgewandt haben. Bekannt ist allerdings, dass die Rechengeschwindigkeit dabei sehr leicht auf der Strecke bleiben kann, wenn man C++ nicht sehr bewusst anwendet. So sind zunächst die Möglichkeiten der C++-Compiler zur automatischen Autoparallelisierung sehr eingeschränkt. Auch OpenMP, das zunächst für Fortran und dann mit leichtem Verzug für C und C++ beschrieben wurde, ignoriert die C++-Besonderheiten weitgehend, was dann auch leicht zu Inkompatibilitäten zwischen verschiedenen C++-Compilern führt. Überhaupt hinkte und hinkt die OpenMP-Implementierung in zahlreichen C++-Compilern hinterher, was dann auch dazu führt, dass bislang OpenMP in C++-Produktionscodes noch wenig verbreitet ist. In Zusammenarbeit mit dem Institut für Numerische Mathematik der RWTH Aachen wurde dieser Problemkreis bei der Parallelisierung des DROPS-Codes, eines adaptiven Finite-Element Codes für Strömungssimulation, und im Rahmen einer Diplomarbeit näher untersucht [7]. Dabei wurden noch weitere C++-spezifische Probleme der OpenMP-Parallelisierung identifiziert, die bislang nicht hinreichend adressiert worden waren. Das automatische Initialisieren von Objekten etwa durch Konstruktoren der C++

4 Standard Template Libary (STL) kann auf ccnuma-architekturen zu einer sehr ungünstigen Speichernutzung führen, die die Skalierbarkeit drastisch einschränken können, wenn, wie üblich, die First-Touch-Mechanismen greifen. Erst der gezielte und vorsichtige Einsatz von bestimmten STL-Datentypen und Methoden mit überschreiben von Allokatoren, oder das explizite Migrieren von Daten, was allerdings noch von keinem Standard unterstützt wird, kann hier Abhilfe verschaffen. Auch das häufige und teilweise verdeckte Aufrufen der Speicherverwaltung in Parallelen Regionen kann je nach Betriebssystem zu Ineffizienzen führen, die man durch Überstülpen einer eigenen Speicherverwaltung ausmerzen kann. [9,10,11] Letztendlich wurde immerhin bei 16 Threads ein Speedup von etwa 8-11 relativ zum Originalprogramm erreicht, allerdings stark von der Maschinenarchitektur und dem verwendeten Compiler abhängig. Dennoch lässt sich feststellen, dass sich OpenMP in diesem Zusammenhang als leistungsfähiger und deutlich einfacher in der Programmierung als MPI erwiesen hat. 5 Geschachtelte Parallelisierung mit OpenMP Schon das Herausziehen der Parallelen Region aus der Routine, in der sich eine parallele Schleife befindet, macht von dem so genannten Orphaning in OpenMP Gebrauch. Dabei befinden sich Direktiven, die zueinander in Beziehung stehen, in verschiedenen Routinen, denn die Binding Region des parallelen Schleifenkonstrukts ist die umschließende Parallele Region. In Routinen, die in einer Parallelen Region aufgerufen werden können, muss plötzlich der Geltungsbereich aller verwendeten Variablen neu berücksichtigt werden und es muss klar entschieden werden, ob sie private sind oder shared, d.h. ob sie nur von dem ausführenden Thread aus sichtbar sind, oder von allen Threads des zugehörigen Thread-Teams. Diese Tatsache erfordert ein zukünftig wichtiges, grundlegendes Umdenken bei der Programmierung, unter Berücksichtigung der Tatsache, dass in naher Zukunft wegen der sich durchsetzenden Multi-Core-Prozessorarchitektur jeder Rechner ein Parallelrechner sein wird und daher auch möglicherweise bald (fast) jedes Programm ein paralleles Programm. Der Begriff des Gültigkeits- oder Sichtbarkeitsbereiches einer jeden Variablen (scope) bekommt damit eine neue Dimension. Insbesondere krankt die derzeitige OpenMP-Spezifikation daran, dass in C++ einzelne statische Membervariablen eines Objektes nicht privatisiert können. OpenMP erlaubt auch die Parallelisierung auf höherer Ebene: Dort wo bisher typischerweise MPI genutzt wurde, steht nun OpenMP als Alternative zur Verfügung und bietet mit dem Shared-Memory-Konzept und den flexiblen OpenMP-Schleifenschedulingmechanismen dort Vorteile, wo etwa auf großen gemeinsamen Datenbereichen gearbeitet werden soll oder wo bei Lastungleichgewichten eine dynamische Aufteilung der Arbeit notwendig ist. Die Kombination von mehreren Parallelisierungsebenen führt dann zur geschachtelten Parallelisierung, die von Anfang an in der OpenMP-Spezifikation berücksichtigt wurde, aber nur zögerlich von den Compiler-Herstellern implementiert

5 wurde. Die ersten Erfahrungen brachten auch schnell Mängel der Spezifikation zu Tage, die hoffentlich mit der nächsten Version behoben werden können. Das in C++ geschriebene Bilderkennungsprogramm FIRE [12,13] bietet drei mögliche Ebenen zur Parallelisierung an, von denen die beiden äußeren schon einen hervorragenden Speed-up von 133 bei 144 Threads liefern. Die Berechnung von Kritischen Punkten zur Visualisierung (ebenfalls in C++ geschrieben) in einer Virtuellen Umgebung [14] macht sowohl von der geschachtelten Paralleliserung auf 3 Ebenen Gebrauch, als auch von den Möglichkeiten des dynamischen Schleifenscheduling auf allen Ebenen. Hier wurden die dynamischen Lastbalancierungsmöglichkeiten von OpenMP sehr vorteilhaft eingesetzt, um eine krasse Arbeitsimbalance im zeitlichen Verlauf des Programms zu managen. Je nach Datensatz liefert das Programme einen Speed-up von bis zu mit 144 Threads! Fortran erlaubt eine weitergehende globale Programmanalyse, auf deren Basis eine tiefgreifendere automatische Parallelisierung von Programmpaketen möglich ist, wenn dem Programmierer die Möglichkeit gegeben wird, dem Analysetool zusätzliche Informationen über das Programm zu geben. Davon macht das ParaWise-Toolkit Gebrauch, dass anfangs von der University of Greenwich unter dem Namen CAPtools entwickelt wurde, und jetzt von der Firma Parallel Software Products vermarktet und in Zusammenarbeit mit NASA Ames weiterentwickelt wird. Dieses Tool wurde anfangs für die MPI-Parallelisierung entwickelt, aber dann auch zur Verwendung von OpenMP erweitert. In Zusammenarbeit mit der Firma Parallel Software Products wurde der Navier-Stokes-Solver TFS auf zwei Ebenen parallelisiert [15,16]. Auch hier wurde von dem dynamischen Schleifenscheduling Gebrauch gemacht, da die Blöcke des zugrunde liegenden 3D-Gitters sehr unterschiedlich groß sind und ein drastisches Lastungleichgewicht bewirken. Dabei zeigten sich besonders die Schwächen der Unterstützung von geschachtelter Parallelisierung auf einer ccnuma-maschine wie der Sun Fire E25K. Erst nach Einsatz von Solaris-spezifischen Maßnahmen zum Prozessor-Binding und zur Daten-Migration in Verbindung mit einer von Sun gelieferten experimentellen Version der Threading-Library wurde jetzt kürzlich ein Speed-up von 25 erreicht mit 64 Threads. Im Vergleich zu einem Speed-up von maximal 5 bis 6, wenn nur eine Parallelisierungsebene aktiviert wird, ist dies ein beachtlicher Fortschritt. 6 Die Kombination von OpenMP und MPI Selbstverständlich können Parallelisierungsmaßnahmen mit MPI und OpenMP auch kombiniert werden, wenn die MPI-Bibliothek hinreichend thread-safe ist. Auf höherer Ebene bietet sich eine MPI-Parallelisierung an und darunter eine OpenMP-Parallelisierung oder automatische Parallelisierung auf Schleifenebene. Auf großen Shared-Memory-Maschinen kann bei solchen hybriden Ansätzen ein Lastungleichgewicht auf der höheren Ebene ausgeglichen werden, in dem man den MPI-Prozessen, die eine größere Last haben, mehr Threads zuordnet als den MPI-Prozessen mit geringerer Last. Das kann man einfach statisch durchführen,

6 aber auch adaptiv. Dazu wurde die Dynamic-Thread-Balancing-Bibliothek entwickelt, die einfach von der MPI-Profiling-Schnittstelle Gebrauch macht, so dass diese Bibliothek sehr einfach eingesetzt werden kann [17,18]. 7 Von OpenMP zu MPI Häufig ist es einfacher, Algorithmen mit OpenMP zu parallelisieren als mit MPI. Das ist etwa bei rekursiven Algorithmen der Fall, wie zum Beispiel bei der Adaptiven Integration. Hier kann man einen Stack-orientierten Algorithmus verwenden um die Rekursion abzuwickeln, oder das Workqueueing, eine Erweiterung der OpenMP-Spezifikation von Intel [19]. Besonders elegant ist die Parallelisierung aber mit einer rekursiv geschachtelten OpenMP-Parallelisierung durchführbar. Nun sind große Shared-Memory-Maschinen, die für die OpenMP- Programmierung ja notwendig sind, relativ teuer, während PC-Cluster, auf denen MPI-Programme ablaufen können, relativ preiswert sind. Dies wirft die Frage auf, ob man den Algorithmus, der zur OpenMP-Parallelisierung verwendet wurde, mit geringem Programmieraufwand auch auf MPI übertragen kann, insbesondere unter Ausnutzung des immer breiter verfügbar werdenden MPI-2 Standards. Zwei Ansätze bieten sich hier an: Wenn die MPI-Bibliothek den höchsten Grad der Thread-Safety anbietet, so dass jeder Thread per MPI kommunizieren kann, kann der OpenMP-Algorithmus auf einem MPI-Prozess ablaufen und jedem Thread wird ein separater MPI-Workerprozess zugeordnet, auf den die rechenintensiven Arbeiten des zugehörigen Threads ausgelagert werden. Ein anderer Ansatz nutzt die One-Sided-Communication-Mechanismen von MPI-2, um den Zugriff auf shared-variablen im korrespondierenden OpenMP-Algorithmus zu ersetzen. Beide Ansätze funktionieren im Falle der Adaptiven Integration, allerdings zeigt der zweite Ansatz derzeit noch eine beschränkte Skalierbarkeit. Insgesamt sind diese Ansätze doch recht interessante Varianten für eine Ad-hoc-Parallelisierung von Anwenderprogrammen, solange diese eine entsprechende Kommunikationsstruktur aufweisen. Entsprechende Arbeiten dauern an. 8 Abschließende Bemerkungen Indem Rechner-Cluster die Vektorrechner in der Domäne des Supercomputing zurückgedrängt haben, hat sich auch das Message-Passing mit MPI als dominierendes Parallelisierungparadigma durchgesetzt. Mit der zunehmenden Verfügbarkeit von Shared-Memory-Parallelrechnern etabliert sich nun die Shared- Memory-Programmierung mit OpenMP als Alternative und Ergänzung. Die sich in jüngster Zeit massiv abzeichnende Verbreitung von Multi-Core-Prozessoren als Grundbaustein von allen Rechnertypen wird OpenMP weiter vorantreiben. Da sich die Geschwindigkeit der einzelne Prozessorkerne nicht mehr wie in den

7 letzten Jahr üblich erhöhen wird, kann eine weitere Programmbeschleunigung nur durch weitergehende Parallelisierung erreicht werden. Eine Verbesserung der Skalierbarkeit wird in vielen Fällen nur durch ein Bündel von Parallelisierungsmaßnahmen zu erreichen sein, d.h. durch Kombination von mehreren Parallelisierungsebenen und Parallelisierungsparadigmen. Geschachtelte und hybride Parallelisierung wird vermehrt anzutreffen sein. Die Shared- Memory-Programmierung wird zudem helfen, den Hauptspeicherbedarf bei einem sich ständig erhöhenden Datenvolumen zu drosseln und damit auch die Hardwarekosten zu reduzieren. Da die Softwareentwicklung der Hardwareentwicklung meist deutlich hinterherhinkt, kann auf die Notwendigkeit der Parallelisierung und insbesondere der Shared-Memory-Programmierung nicht genügend hingewiesen werden. Daher wird das Experimentieren und Erforschen von Strategien zur OpenMP-Programmierung und das Vorantreiben der Standardisierungsvorhaben des OpenMP Architecture Review Boards immer wichtiger. Dazu gehören auch die Evaluierung von innovativen Architekturen, wie der UltraSPARC T1-basierten Sun Fire T2000, die sich mit 8 Cores und je 4 Threads mit einem einzigen Prozessorchip schon als 32-faches SMP-System dem Nutzer präsentiert [19], als auch von innovativen Softwareprodukten, wie der Cluster OpenMP-Implementierung von Intel, welche das OpenMP Programmiermodell auf ein Cluster projeziiert und zumindest für sogenannte RMS (Recognition, Mining, Synthesis) Workloads, wo das Lesen von Daten im Vordergrund steht, auf kleineren Clustersystemen ggf. effizient unterstützen könnte.

8 Literatur 1. T. Volmar, B. Brouillet, H.E. Gallus, H. Benetschik: Time Accurate 3D Navier- Stokes Analysis of a 1 Stage Axial Flow Turbine. AIAA , Dieter an Mey, Stephan Schmidt, From a Vector Computer to an SMP-Cluster - Hybrid Parallelization of the CFD Code PANTA, EWOMP 2000, Edinburgh 3. L. Wang, N. Peters: The length scale distribution function of the distance between extremal points in passive scalar turbulence, to appear in Journal of Fluid Mechanics (2006) vol. 554, p Y. Lin, C. Terboven, D. an Mey, N. Copty: Automatic Scoping of Variables in Parallel Regions of an OpenMP Program. WOMPAT 04, Houston, USA, May T.M. Haarmann, W.W. Koschel: Numerical Simulation of Heat Loads in a Cryogenic H2/O2 Rocket Combustion Chamber. ZAMM - J. Applied Mathematics and Mechanics, Volume 2, Issue 1, March 2003, D. an Mey, T. Haarmann: Pushing Loop-Level Parallelization to the Limit. EWOMP 2002, Rome, Italy, Sept S. Gross, J. Peters, V. Reichelt, A. Reusken: The DROPS package for Numerical Simulations of Incompressible Flows using Parallel Adaptive Multigrid Techniques. ftp://ftp.igpm.rwth-aachen.de/pub/reports/pdf/igpm211 N.pdf 8. C. Terboven, A. Spiegel, D. an Mey, S. Gross, V. Reichelt: Parallelization of the C++ Navier-Stokes Solver DROPS with OpenMP. Proc. ParCo 2005, Malaga, Spain, Sept Vol 33 in the NIC book series, Research Centre Jülich, Germany. 9. C. Terboven, D. an Mey: OpenMP and C++. IWOMP 2006, Reims, France 10. G. Bracha, W. Cook: Mixin-based inheritance. Proc. Object-Oriented Programming: Systems, Languages and Applications (OOPSLA) 11. C. Terboven: Shared-Memory Parallelisierung von C++ Programmen. Diploma thesis. 12. C. Terboven, T. Deselaers, C. Bischof, H. Ney: Shared-Memory Parallelization for Content-based Image Retrieval. Workshop 2006 on Computation Intensive Methods for Computer Vision 13. T. Deselaers, D.Keysers, H. Ney,: Features for image retrieval a quantitative comparison. DAGM 2004, Pattern Recognition, 26th DAGM Symposium, Number 3175 in Lecture Notes in Computer Science, Tübingen, Germany (2004) A. Gerndt, S. Sarholz, M. Wolter, D. an Mey, T. Kuhlen, C. Bischof: Nested OpenMP for Efficient Computation of 3D Critical Points in Multi-Block CFD Datasets. SC 2006, Nov 2006, Tampa, USA 15. I. Hörschler, C. Brücker, W. Schröder, M. Meinke: Investigation of the Impact of the Geometry on the Nose Flow. European Journal of Mechanics B/Fluids, Volume 25, Issue 4, July-August 2006, Pages S. Johnson, C. Ierotheou, A. Spiegel, D. an Mey, I. Hörschler: Nested Parallelization of the Flow Solver TFS using the ParaWise Parallelization Environment. IWOMP 2006, Reims, France 17. A. Spiegel, D. an Mey, C. Bischof: Hybrid Parallelization of CFD Applications with Dynamic Thread Balancing. Proc. PARA04 Workshop, Lyngby, Denmark, LNCS 3732, J. Dongarra, K. Madsen, J. Wasniewski, Eds., pp , Springer, A. Spiegel, D. an Mey: Hybrid Parallelization with Dynamic Thread Balancing on a ccnuma System. EWOMP 2004, Stockholm, Sweden 19. D. an Mey: Two OpenMP Programming Patterns. EWOMP 2003, Aachen, Germany