Parallele Architekturen - Forschungszentrum Jülich
Transcription
Parallele Architekturen - Forschungszentrum Jülich
Einführung in die Parallelprogrammierung Annika Hagemeier Jülich Supercomputing Centre (JSC) Forschungszentrum Jülich Inhalt der Vorlesung Parallele Architekturen und Programmiermodelle Einführung in MPI: Punkt-zu-Punkt Kommunikation (blockierend, nicht-blockierend) Kollektive Kommunikation (blockierend, nicht-blockierend) Abgeleitete Datentypen Kommunikatoren Virtuelle Topologien Einführung in OpenMP: Parallele Regionen Schleifenparallelisierung mit verschiedenen SchedulingStrategien Worksharing-Konstrukte Synchronisation 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 2 Einführung in die Parallelprogrammierung Parallele Architekturen und Programmiermodelle Annika Hagemeier Jülich Supercomputing Centre (JSC) Forschungszentrum Jülich Inhalt Motivation Parallele Architekturen verteilter Speicher gemeinsamer Speicher hybride Systeme Prozesse und Threads Ziel der Parallelverarbeitung Von Jägern und Sammlern Arbeitsaufteilung Leistungsanalyse paralleler Programme Probleme bei der Parallelisierung 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 4 Literatur Parallel Programming in C with MPI and OpenMP Michael J. Quinn (2003) ISBN: 007-282256-2 Parallel Programming Barry Wilkinson, Michael Allen (2005) ISBN: 0-13-191865-6 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 5 Warum parallel programmieren? physikalische Grenzen der sequentiellen Architekturen sind mehr oder weniger erreicht die Taktzeit kann nicht beliebig verkleinert werden die CPU-Speicher-Bandbreite ist begrenzt hohe Taktraten setzen kleine physikalische Größen von Systemen voraus (Lichtgeschwindigkeit ist begrenzt) hohe Taktraten und hohe Packungsdichten führen zu großer Hitzeentwicklung, die vom System abgeleitet werden muss größer werdender Unterschied zwischen Speicherzugriffszeit und Prozessortaktrate Prozessoren erreichten einen immer geringer werdenden Anteil ihrer Peak-Performance Anwendungen benötigen große Mengen an Speicher Verkürzung der Zeit bis Ergebnisse vorliegen Lösung von komplexeren Problemen 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 6 Parallele Architekturen: Distributed Memory alle Kerne haben ihren eigenen lokalen Speicher und sind über ein Kommunikationsnetzwerk miteinander verbunden relativ schwierig zu Programmieren: explizite Verteilung der Daten explizite Kommunikation über Nachrichtenaustausch explizite Synchronisation Programmiermodelle: Message-Passing: MPI, PGAS, ... Data parallelism: HPF sehr hoch skalierbar 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 7 Parallele Architekturen: Shared Memory alle Kerne haben Zugriff auf alle Speichermodule (gemeinsamer Adressraum) Symmetric Multi-Processing (SMP) einfacher zu Programmieren: keine Verteilung der Daten nötig implizite Kommunikation über gemeinsame Daten explizite Synchronisation Programmiermodelle: automatische Parallelisierung durch den Compiler OpenMP MPI, PGAS 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 8 Parallele Architekturen: Hybride Systeme Aufgrund des Trends in Richtung Mehrkern-Architekturen sind fast alle modernen HPC-Systeme Cluster aus SMPKnoten Non-Uniform Memory Access (NUMA) Shared Memory innerhalb eines Knotens Distributed Memory zwischen den Knoten Programmiermodelle: Message-Passing zwischen allen Knoten Message-Passing zwischen Knoten, Multi-Threading innerhalb der Knoten Partitioned Global Address Space (PGAS) zwischen allen Knoten 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 9 Prozesse und Threads (1) Thread: ein Thread ist ein Stück Code zusammen mit einem Zustand, gespeichert in einem Register, Stack oder Programm-Pointer eine “leichtgewichtige” Einheit für den Ablauf von Befehlen in vielen Betriebssystemen ist ein Thread die kleinste Einheit, die verwaltet werden kann Prozess: Prozesse sind Objekte, die vom Betriebssystem bereitgestellt werden zur Ausführung von Programmen ein Prozess ist eine Instanz eines Computerprogramms ein sequentieller Prozess besteht aus einem Thread, der beginnend beim Main das Programm ausführt 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 10 Prozesse und Threads (2) Der Thread hat Zugriff auf: Unterstützt das Betriebssystem Multi-Threading, kann ein Prozess aus mehreren Threads bestehen einen Stack zur Abspeicherung lokaler Daten einen Heap zur Abspeicherung dynamischer Daten einen Speicherbereich zur Speicherung globaler statischer Daten diese können zur Laufzeit dynamisch kreiert und zerstört werden jeder Thread kann auf den Heap und die globalen Daten zugreifen jeder Thread hat jedoch seinen eigenen Stack und Registersatz Konzepte paralleler Programme: mehrere Prozesse + Mechanismus zur Kommunikation zwischen den Prozessen Shared-Memory Computer mit Multi-Threading Kombination aus beiden 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 11 Single-threaded vs. Multi-threaded Files Global Data Registers Heap Stack Sequential Code Single-threaded process 27. Oktober 2014 Files Global Data Registers Heap Registers Registers Stack Stack Stack Sequential Code Sequential Code Sequential Code Multi-threaded process Parallele Architekturen und Programmiermodelle 12 Parallelisierung Zwei wichtige Hardware-Ressourcen: Prozessor Speicher Parallelisierung bedeutet: Verteilung der Arbeit auf die Prozessoren Synchronisation der verteilten Arbeit ist der Speicher verteilt bedeutet Parallelisierung zusätzlich: Verteilung der Daten Austausch von Daten zwischen lokalen und entfernten Prozessoren 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 13 SPMD: Parallelprogrammierungs-Paradigma SPMD = Single Program Multiple Data der Programmierer schreibt ein Programm, das auf allen Prozessoren ausgeführt wird SPMD ist das grundlegende Paradigma zur Implementierung von parallelen Programmen MPMP (= Multiple Programs, Multiple Data) kann mit SPMD emuliert werden if (my_id == 42) then do_something() else do_something_else() endif meist übernimmt ein Prozess die Funktion des Masters: nimmt Initialisierungen vor, verteilt die Arbeit/Daten, ... meist wird der Prozess mit dem Rang 0 als Master gewählt 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 14 Parallele Programmiermodelle Message Passing Interface (MPI) OpenMP Programmiermodell für Architekturen mit verteiltem Speicher (auch auf Architekturen mit gemeinsamem Speicher verwendbar) Benutzer definiert, wie Daten und Arbeit verteilt werden Benutzer bestimmt, wann und wie kommuniziert wird basiert auf expliziten Aufrufen von MPI-Bibliotheksfunktionen Programmiermodell für Architekturen mit gemeinsamem Speicher automatische oder initiierte Verteilung der Arbeit kein explizites Verteilen der Daten und Kommunikation Synchronisation ist implizit (kann auch benutzerdefiniert sein) PGAS datenparalleles Programmiermodell (nur ein Adressraum) Verteilung von Daten und Arbeit wird vom Compiler realisiert Vektor-Statements zum Ausdruck von datenparallelen Operationen sind möglich 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 15 Ziel der Parallelverarbeitung Durch die Aufteilung einer Aufgabe in Teilaufgaben, die gleichzeitig bearbeitet werden können, soll eine Leistungssteigerung erzielt werden. Man unterscheidet: Sequentielle Verarbeitung: nacheinander ausführen der Teilaufgaben Parallele Verarbeitung: es gibt Zeitabschnitte in der Verarbeitung, in der Teilaufgaben gleichzeitig bearbeitet werden Voraussetzungen: 1. Aufteilungsmöglichkeit existiert und wird erkannt 2. mehrere Bearbeiter stehen zur Verfügung 3. gleichzeitig ⇒ möglichst unabhängig 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 16 . . . von Sammlern 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 17 . . . von Sammlern (Fläche a) mit T(vom): Zeit für den Weg vom Dorf T(zum): Zeit für den Weg zum Dorf (etwas länger, da beladen) T(a): Zeit zum Abpflücken der gesamten Fläche a.) für eine Person dann gilt: Tp = T(vom) + T(a) / p + T(zum) also: je mehr Bearbeiter (Prozessoren), je kürzer die Gesamtzeit 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 18 . . . von Sammlern (Fläche b) Die Gesamtfläche ist bei b.) kleiner als bei a.). Dennoch werden die Sammler nicht früher fertig als bei a.), da Wartezeiten entstehen. Wenn man die Fläche b.) so auf die Sammler verteilt, dass jeder gleich viel erhält, kann die Gesamtzeit verkürzt werden. 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 19 . . . von Sammlern (Fläche c) Für c.) gilt entsprechendes wie für b.): im schattigen Gebiet wachsen weniger Trauben, daher fällt dort weniger Arbeit an. Da die Flächenform und der Bewuchs von vornherein bekannt ist, kann schon vor dem Beginn eine optimale Aufteilung für die Gleichverteilung von Arbeit gefunden werden. ⇒ statische Lastverteilung (load balancing) Dies ist auch angebracht, wenn das Arbeitsvermögen der Sammler (Prozessoren) unterschiedlich ist 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 20 . . . von Jägern Aufgabe der Jäger: Eine Gruppe von p Jägern gehen gemeinsam vom Dorf in den Wald. Dieser ist an 3 Seiten mit einem Zaun begrenzt. Von der offenen Seite her versuchen sie ein Wildschwein in eine Ecke zu treiben. Damit das Schwein nicht zwischen ihnen entkommt, müssen sie immer wieder ihrem Nachbarn ihre Position durchgeben. Am Ende wird das Schwein erlegt und gemeinsam zum Dorf getragen Form des Waldstücks: Wildschwein 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 21 . . . von Jägern Ähnlich wie beim Weinberg kann das Waldstück in p gleiche Teile unterteilt werden. Die Aktionen der einzelnen Jäger sind hier aber nicht unabhängig voneinander. Sie müssen sich von Zeit zu Zeit über ihre Position verständigen. Je nach Bewegung des Schweins müssen einige langsamer gehen, damit keine Lücken entstehen. 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 22 . . . Analogie zu Parallelrechnern Was haben Jäger und Sammler mit Parallelrechnern zu tun? Gruppenmitglieder = Weinberg / Wald = Streifen des Gebiets = Weintraube / Schwein= Weinlese, Jagd = Anzahl Prozessoren p Gebiet (im Sinne der Mathematik) Datenstruktur Daten Arbeit (bearbeiten der Daten) Unterschiede zwischen beiden Beispielen: Sammler: keine Kommunikation zwischen Prozessoren keine zusätzlichen Verarbeitungszeiten keine Synchronisation zwischen den Prozessoren nötig keine Wartezeiten (barrier) keine Abhängigkeit zwischen den Streifen 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 23 Aufteilung in parallele Arbeitspakete Bei der Aufteilung unterscheidet man: 1. Domain Decomposition (Gebietszerlegung) Statische oder dynamische Aufteilung eines Datengebiets in Bereiche gleicher Prozessorarbeit. Alle Gebiete werden mit dem selben Programmteil parallel verarbeitet. Kommunikation erfordert “enggekoppelte” Prozessoren geeignet für homogene Plattformen am häufigsten verwendet in HPC 2. Functional Decomposition (Funktionsaufteilung) Unterschiedliche Programmteile, Unterprogramme, Module werden auf Prozessoren verteilt und parallel bearbeitet. verschiedene Rechnerarchitekturen für unterschiedliche Programmteile einsetzbar aufwändiger zu Implementieren 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 24 Domain Decomposition: statische Aufteilung Aufteilung der Daten auf die Hauptspeicher der Prozessoren Unterschiedliche Farben kennzeichnen unterschiedliche Prozessoren Unterschiedliche Aufteilung soll die Kommunikation zwischen den Prozessoren minimieren oder bestimmte Hardware-Eigenschaften des Verbindungsnetzwerkes ausnutzen 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 25 Domain Decomposition: dynamische Aufteilung dynamische Aufteilung eines Gebietes in Bereiche gleicher Prozessorarbeit z.B. Multigrid-Methoden Lastverformung (höchste Genauigkeit = Rechenarbeit bei stärkster Materialspannung) 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 26 Functional Decomposition Aufteilung in Bereiche unterschiedlicher Algorithmen (Programmteile) z.B. Klimamodelle 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 27 Leistungsanalyse paralleler Programme Bestimmend für die Performance paralleler Programme sind: die Geschwindigkeit auf dem Einzelprozessor (Optimierung serieller Programme) die Verteilung des Problems auf die Prozesse / Prozessoren der parallele Zusatzaufwand (Overhead) Interaktion der Prozesse (Kommunikation) Wartezeiten (Idling) Zusätzliche Initialisierungs-/Berechnungs-Arbeit etc. 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 28 Paralleler Overhead Der totale parallele Overhead gibt an, wieviel Zeit von p Prozessoren mehr benötigt wird als vom schnellsten sequentiellen Algorithmus. Für den parallelen Overhead gilt: T O = p T P−T S wobei: T S = serielle Ausführungszeit T P = parallele Ausführungszeit T O = totaler paralleler Overhead Die Ausführungszeiten der p Prozesse werden aufsummiert, um den gesamten Rechenaufwand des parallelen Algorithmus zu beschreiben. 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 29 Speedup Der Speedup gibt an, wieviel schneller ein gegebenes Problem parallel mit p Prozessoren bearbeitet wird verglichen mit dem schnellsten sequentiellen Programm. Der Speedup S(p) für p Prozessoren wird definiert als: sequentielle Ausführungszeit T S S p= = parallele Ausführungszeit TP Idealer Speedup: Idealerweise sollte der Speedup linear mit der Anzahl der Prozessoren p ansteigen, d.h. jeder der Prozessoren bearbeitet genau 1/p-tel des Problems und es gibt keinen parallelen Overhead. 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 30 Effizienz Die Effizienz definiert das Verhältnis von Speedup und eingesetzter Prozessorzahl. Sie gibt an, wie lang die Prozessoren während der Ausführung aktiv waren, also wie gut die zusätzlichen Prozessoren im Parallelbetrieb ausgenutzt werden. Die Effizienz wird definiert als: TS S p E p= = p pT P es gilt: 0E p ≤1 im Idealfall, wenn S 27. Oktober 2014 p= p (kein Overhead) gilt: E p=1 Parallele Architekturen und Programmiermodelle 31 Amdahls Gesetz der Mehraufwand bei parallelen Programmen beschränkt den möglichen Speedup eines parallelen Algorithmus dieser Mehraufwand ist meist selbst nicht parallelisierbar Das Amdahl'sche Gesetz beschränkt den theoretisch möglichen Speedup eines parallelen Algorithmus durch die seriellen (nicht parallelisierbaren) Anteile. Das Amdahl'sche Gesetz lautet: 1 S max p= f 1− f / p wobei: die Problemgröße sei fest f = sequentieller (nicht parallelisierbarer) Anteil (1- f ) = ohne Overhead parallelisierbarer Anteil Für p ∞: S ≤ 1 max 27. Oktober 2014 f Parallele Architekturen und Programmiermodelle 32 Amdahls Gesetz 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 33 Probleme bei der Parallelisierung Paralleler Overhead Data Races / Race Conditions Verklemmung (Deadlocks) Lastbalancierung Serialisierung Nicht reproduzierbar (unterschiedliche numerische Ergebnisse) 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 34 Paralleler Overhead (Speedup in der Praxis) Bei genügend großer Anzahl Prozessoren übersteigt der parallele Overhead den Rechenaufwand, der durch die zusätzlichen Kerne verringert wird 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 35 Data Races / Race Conditions Data Races: ungeregelte gleichzeitige Zugriffe mehrerer Threads auf die gleiche Variable/Speicherstelle Race Condition: Ergebnisse hängen von der Reihenfolge ab, in der die Operationen ausgeführt werden Beispiel: x werde mit 1 initialisiert abhängig davon, welcher Thread schneller ist, wird entweder 1 oder 5 geschrieben Ergebnis ist nicht deterministisch 27. Oktober 2014 x = 5; Parallele Architekturen und Programmiermodelle printf(x); 36 Verklemmung (Deadlocks) Ein Deadlock ist eine Situation in der zwei oder mehr Prozesse auf ein Ergebnis warten, welches nur ein Prozess aus der Gruppe liefern kann. Beispiele: Prozess A wartet auf eine Nachricht von Prozess B, während Prozess B auf eine Nachricht von Prozess A wartet (MPI) Thread A belegt eine Ressource, die ein anderer Thread B haben möchte, Thread B belegt aber eine Ressource, die A gerne bekommen möchte (OpenMP) 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 37 Lastbalancierung (1) Eine Kette ist nur so stark, wie ihr schwächstes Glied. Weinlese ohne Lastbalancierung: Weinlese mit Lastbalancierung: 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 38 Lastbalancierung (2) Lastbalancierung: gleichmäßiges Verteilen der Arbeitslast auf die Prozesse Ziel: Minimierung der (parallelen) Rechenzeit Idealfall: alle Prozesse brauchen gleich lange, um ihre Teilaufgaben zu erfüllen alle Prozesse sind während der Ausführung vollständig ausgelastet Faktoren der Lastbalancierung: Zeit zur Bearbeitung der Daten Zeit zur Kommunikation der Daten Zeit um die Verteilung der Daten zu berechnen lokale Informationen zur Lastbalancierung 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 39 Serialisierung Bestehen im parallelen Programm Abhängigkeiten zwischen den Prozessen, d.h. ein oder mehrere Prozesse müssen auf die Ergebnisse anderer Prozesse warten, kann es zu einer Serialisierung kommen, d.h. die Operationen werden nicht parallel sondern nacheinander ausgeführt. 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 40 Übung Übung 1: Parallele Architekturen und Programmiermodelle 27. Oktober 2014 Parallele Architekturen und Programmiermodelle 41 Einführung in die Parallelprogrammierung Einführung in JUDGE Annika Hagemeier Jülich Supercomputing Centre (JSC) Forschungszentrum Jülich Inhalt Supercomputer am JSC JUDGE Zugang Login über SSH-Schlüssel Module Compiler und Debugger Starten von Programmen Moab-Batchsystem Interaktives Starten von Programmen Abschicken von Batch-Jobs Untersuchung von Programmen Zeitmessung Visualisierung von Messdaten mit GnuPlot 27. Oktober 2014 Einführung in JUDGE 2 Supercomputer am JSC: Historie IBM Power 4+ JUMP, 9 TFlop/s IBM Blue Gene/L JUBL, 45 TFlop/s IBM Power 6 JUMP, 9 TFlop/s JUROPA 200 TFlop/s HPC-FF 100 TFlop/s IBM Blue Gene/P JUGENE, 1 PFlop/s File Server IBM Blue Gene/Q JUQUEEN 5.9 PFlop/s Lustre GPFS JUROPA successor ~ 2 PFlop/s + Booster ~ 10 Pflop/s General-Purpose Cluster 27. Oktober 2014 JUQUEEN successor ~ 50 PFlop/s Highly-Scalable System Einführung in JUDGE 3 JUDGE: Juelich Dedicated GPU Environment Eigenschaften eines Rechenknotens: IBM System x iDataPlex dx360 M3 2 Intel 6-core Prozessoren (Xeon X5650 (Westmere)) 2,66 GHz 96 GB Speicher (DDR3, 1066 MHz) GPU: 2 Nvidia Tesla M2050 (Fermi) (3 GB) auf 54 Knoten GPU: 2 Nvidia Tesla M2070 (Fermi) (6 GB) auf 152 Knoten JUDGE-Cluster: 206 Rechenknoten 2472 Rechenkerne 412 Graphikprozessoren 19,8 TB Speicher Performance: Peak: 239 Teraflops 27. Oktober 2014 Einführung in JUDGE 4 Superrechner am JSC: Vernetzung 27. Oktober 2014 Einführung in JUDGE 5 JUDGE: Zugang (Linux) Zugang über Linux-Shell: Rechnername: judge.fz-juelich.de Login auf JUDGE: ssh -Y train0XX@judge direkter Zugang nur zu Login-Knoten restliche Knoten ausschließlich für Rechnungen Userid: train002 ... train044 (train001: Tutor-Account) gemeinsames Verzeichnis: /homea/hpclab/train001/kurs Userid kann auch außerhalb der Übungs- und Praktikumszeiten für die Programmieraufgaben genutzt werden Dokumentation und Informationen: http://www.fzjuelich.de/ias/jsc/judge 27. Oktober 2014 Einführung in JUDGE 6 JUDGE: Zugang (Windows) zum Einloggen auf den JUDGE benötigt man eine Linux Shell ⇒ Einloggen per ssh (siehe vorherige Folie) Möglichkeiten: Linux installieren (Dual-Boot) Knoppix-CD: Linux wird von CD gebootet, keine Installation notwendig Cygwin: ist eine Linux-ähnliche Umgebung für Windows frei verfügbar unter http://www.cygwin.com/ die entsprechenden Pakete müssen ausgewählt sein 27. Oktober 2014 Einführung in JUDGE 7 JUDGE: Login über SSH-Schlüsselpaar Login auf JUDGE nur mittels SSH-Schlüsselpaar möglich ⇒ Einloggen mittels Passwort ist nicht möglich! das Schlüsselpaar besteht aus einem öffentlichen (id_rsa.pub) und einem privaten (id_rsa) Teil: train001@zam859: ll $HOME/.ssh -rw-------+ 1 hpclab01 kurs 1743 Sep 11 13:20 id_rsa -rw-r--r--+ 1 hpclab01 kurs 397 Sep 11 13:20 id_rsa.pub das Schlüsselpaar muss auf der Workstation, von der aus man sich auf JUDGE einloggen möchte, liegen das Schlüsselpaar muss außerdem mit einer nicht-trivialen Passphrase geschützt werden der öffentliche Teil des Schlüssels wird dann auf JUDGE in der Datei $HOME/.ssh/authorized_keys hinterlegt Achtung: der private Teil des Schlüssels bleibt geheim! Weitere Informationen: http://www.fz-juelich.de/ias/jsc/EN/Expertise/Supercomputers/JUDGE/Userinfo/Access_Environment.html 27. Oktober 2014 Einführung in JUDGE 8 JUDGE: SSH-Schlüsselpaar generieren Ist noch kein Schlüsselpaar auf der Workstation vorhanden, kann dieses wiefolgt generiert werden: neues Schlüsselpaar generieren mittels: train001@zam859: ssh-keygen -b 2048 -t rsa Generating public/private rsa key pair. Verzeichnis auswählen: (<enter> wählt Standardverzeichnis $HOME/.ssh) Enter file in which to save the key (/home/train001/.ssh/id_rsa): Passphrase setzen: Enter passphrase (empty for no passphrase): Enter same passphrase again: Fertig! Your identification has been saved in /home/train001/.ssh/id_rsa. Your public key has been saved in /home/train001/.ssh/id_rsa.pub. Weitere Informationen: http://www.fz-juelich.de/SharedDocs/FAQs/IAS/JSC/EN/Supercomputers/FAQ_generation_ssh_key.html 27. Oktober 2014 Einführung in JUDGE 9 JUDGE: Erreichbarkeit Informationen zu JUDGE: http://www.fzjuelich.de/ias/jsc/judge JUDGE ist nicht immer erreichbar ⇒ Maintenance-Mode, zur Wartung des Systems, für Software-Updates, ... „Message of the Day“ informiert über derzeitigen JUDGEStatus (https://dispatch.fzjuelich.de:8812/HIGHMESSAGES#judge) ####################################################################### # Welcome to JuDGE # # Juelich Dedicated GPU Environment # #---------------------------------------------------------------------# # Information about the system, latest changes, # # user documentation and FAQs: # # * http://www.fz-juelich.de/ias/jsc/judge/ # # * /opt/moab/README_JUDGE # #---------------------------------------------------------------------# # * CUDA versions 5.5 available (module load cuda/5.5). Examples at # # /usr/local/cuda/cuda-5.5_Samples/ # # * python numpy upgraded to 1.7.1 (Python 2.6) # # * new moab 6.1.11 # # * memory overcommitment on compute nodes is disabled # # * new psmpi2 version 5.0.28 available # # * psmpi2-pgi 5.0.28 compiled using pgc++ for mangling compliance. # ####################################################################### 27. Oktober 2014 Einführung in JUDGE 10 Module Module erlauben den einfachen Wechsel zwischen verschiedenen Versionen von Bibliotheken und Software Nützliche Kommandos: Kommando module avail module list module load <mod> module unload <mod> module purge module help Bedeutung zeigt alle verfügbaren Module an listet alle geladenen Module auf lädt das Modul mod löscht das Modul mod löscht alle Module listet Informationen zur Benutzung auf Beispiel: train001@judge:~> module list Currently Loaded Modulefiles: 1) parastation/intel 2) mkl/10.2.5.035 3) intel/11.1.072 train001@judge:~> module avail ------------ /usr/local/modulefiles/COMPILER -----------intel/11.1.059 intel/14.0.3 gcc/4.5.1-64bit intel/11.1.072(default) pgi/11.7 GCC/4.4.6 ... 27. Oktober 2014 Einführung in JUDGE 11 JUDGE: Compiler (1) Serielles Programm: C / C++: Fortran: Beispiel: icc / icpc ifort icc -o my_prog my_prog.c MPI-Programm: C / C++: Fortran: Beispiel: mpicc / mpicxx mpif77 / mpif90 mpicc -o my_prog my_prog.c OpenMP-Programm: C / C++: Fortran: Beispiel: 27. Oktober 2014 icc / icpc ifort icc -openmp -o my_prog my_prog.c Einführung in JUDGE 12 JUDGE: Compiler (2) Hybrides (MPI/OpenMP) Programm: C / C++: Fortran: Beispiel: mpicc / mpicxx mpif77 / mpif90 mpicc –openmp -o my_prog my_prog.c Weitere Informationen zur Compilation: http://www.fz-juelich.de/ias/jsc/EN/Expertise/Supercomputers/JUROPA/UserInfo/CompileAndExecute.html Anmerkung: OpenMP 4.0 wird erst ab Intel-Compiler-Version 14.0 unterstützt (wobei auch dort noch nicht alle Features unterstützt werden) Der Default-Compiler auf JUDGE ist jedoch 11.1 Daher muss die Version 14.0 über folgende Befehle geladen werden: module unload intel mkl module load intel/14.0.3 27. Oktober 2014 Einführung in JUDGE 13 JUDGE: DDT Parallel Debugger entwickelt von der Firma Allinea Benutzung auf JUDGE: Programm compilieren und linken mit Option -g: mpicc -g -o my_proc my_proc.c interaktive Partition allokieren (mit X-Forwarding): msub -I -X -l nodes=2:ppn=12 evtl. Modul laden: module load ddt Debugger starten: ddt ./my_proc Weitere Informationen zu DDT: im ILIAS unter Sonstiges Material -> Dokumentation 27. Oktober 2014 Einführung in JUDGE 14 JUDGE: DDT -> Starten Ausführbares Programm Anzahl der Prozesse einstellen 27. Oktober 2014 Einführung in JUDGE 15 JUDGE: DDT -> Hauptfenster Prozesskontrolle Prozessgruppen Source Code Variablen Stack Trace 27. Oktober 2014 Expression Evaluator Einführung in JUDGE 16 JUDGE: Debugger Totalview Benutzung auf JUDGE: Programm compilieren und linken mit Option -g: mpicc -g -o my_proc my_proc.c interaktive Partition allokieren (mit X-Forwarding): msub -I -X -l nodes=2:ppn=8 evtl. Modul laden: module load totalview Debugger starten: totalview ./my_proc Weitere Informationen zu Totalview: https://computing.llnl.gov/tutorials/totalview/ 27. Oktober 2014 Einführung in JUDGE 17 JUDGE: Totalview -> Starten 1. Toolbar “Parallel” auswählen 2. MPICH2 auswählen 3. Anzahl der Prozesse einstellen 27. Oktober 2014 Einführung in JUDGE 18 JUDGE: Totalview -> Hauptfenster Toolbar lokale Variablen Source Code Stack Trace Root Window (Überblick über alle Prozesse) Break Point 27. Oktober 2014 Einführung in JUDGE 19 JUDGE: Arbeitsverteilung Login-Knoten: Programmentwicklung (Kompilation, Editieren, usw.) Post-Processing (z.B. grafische Auswertung) Überprüfung von Job- und Maschinenstatus Abschicken von Batch-Jobs oder Starten interaktiver Anwendungen Rechenknoten: Ausführen von Simulationsrechnungen alle Compute-Knoten laufen unter der Kontrolle des Moab/Torgue-Batchsystems kein direktes Einloggen auf Rechenknoten GPFS-Knoten: zur Manipulation von Daten Zugriff zum GPFS-Dateisystem 27. Oktober 2014 Einführung in JUDGE 20 Moab-Batchsystem Job-Management-System zur Verwaltung und Koordination von anstehenden Jobs Verwendet Torque als Resource-Manager Anpassung der Job-Anfordungen an die verfügbaren SystemRessourcen ⇒ optimale Nutzung und gerechte Aufteilung der Ressourcen unter den Benutzern JUDGE: 2 Möglichkeiten Jobs zu starten interaktives Starten von Programmen Abschicken von Batch-Jobs Jobs kommen zunächst in eine Warteschlange und werden erst gestartet, wenn sie an der Reihe sind Reihenfolge der Jobs wird anhand von Prioritäten festgelegt 27. Oktober 2014 Einführung in JUDGE 21 Moab-Batchsystem: Job-Limits jeder Benutzer erhält einen eigenen Rechenknoten ⇒ kleinste Reservierungseinheit: 1 Knoten (= 8 Prozessoren) Interaktive Jobs: Max. Anzahl Knoten: 8 (default: 1) Max. Zeit (Wall-Clock): 8 Std. (default: 1 Std.) Batch-Jobs (normal): Max. Anzahl Knoten: 122 (default: 1) Max. Zeit (Wall-Clock): 24 Std. (default: 24 Std.) Batch-Jobs (lang): Max. Anzahl Knoten: 16 (default: 1) Max. Zeit (Wall-Clock): 72 Std. (default: 36 Std.) 27. Oktober 2014 Einführung in JUDGE 22 Interaktives Starten von Programmen dient zum Starten kleinerer Jobs bzw. zum Testen Starten einer interaktiven Session mit msub -I -l nodes=2:ppn=8,walltime=00:30:00 (reserviert 2 Knoten mit je 8 Prozessoren für 30 Minuten) Beispiel train001@judge:~> msub -I -l nodes=2:ppn=8,walltime=00:30:00 qsub: waiting for job 2126602.judgem to start qsub: job 2126602.judgem ready Directory: /homea/hpclab/train001 Thu Oct 16 09:02:10 CEST 2014 train001@judge034:~> mpiexec -np 4 ./hello Hello world! Hello world! Hello world! Hello world! Weitere Infos unter: http://www.fzjuelich.de/ias/jsc/EN/Expertise/Supercomputers/JUDGE/Userinfo/Quick_Introduction.html 27. Oktober 2014 Einführung in JUDGE 23 Abschicken von Batch-Jobs eine Kommando-Datei (Batch-Script) muss geschrieben werden, in der die Eigenschaften des Jobs (z.B. Anzahl der Prozessoren und Knoten) spezifiziert sind dient zum Starten großer Jobs Starten eines Batch-Jobs: msub run.ll Nützliche Schlüsselwörter: Anzahl der Knoten und Anzahl der Prozesse pro Knoten #MSUB -l walltime=<tt:mm:yy> Zeitlimit für den Job #MSUB -e <path for errors> Verzeichnis für Error-Files #MSUB -o <path for output> Verzeichnis für Ausgabedateien #MSUB -v tpt=<threads per task> Anzahl der Threads (nur für OpenMP oder hybride Jobs) #MSUB -m n|a|b|e soll der Benutzer benachrichtigt werden (never, on abort, beginning, end) #MSUB -l nodes=<nodes> :ppn=<procs> Weitere Informationen unter: http://www.fzjuelich.de/ias/jsc/EN/Expertise/Supercomputers/JUDGE/Userinfo/Quick_Introduction.html 27. Oktober 2014 Einführung in JUDGE 24 Abschicken von Batch-Jobs (Beispiel) Batch-Script (run.ll): #!/bin/bash -x #MSUB -l nodes=2:ppn=4 #MSUB -l walltime=00:01:00 #MSUB -e /homea/hpclab/train001/kurs/hello-error.txt #MSUB -o /homea/hpclab/train001/kurs/hello-out.txt #MSUB -M a.hagemeier@fz-juelich.de #MSUB -m abe cd $PBS_O_WORKDIR mpiexec -np 8 ./hello Stdout: train001@judge:~/kurs> msub run.ll Beim Starten von Jobs wird das HomeVerzeichnis als Arbeitsverzeichnis gewählt. Daher muss vor dem Ausführen des Programms in das aktuelle Verzeichnis gewechselt werden. 27. Oktober 2014 2126799 train001@judge:~/kurs> cat hello-error.txt + cd /homea/hpclab/train001/kurs + mpiexec -np 8 ./hello train001@judge:~/kurs> cat hello-out.txt Hello world! Hello world! Hello world! Hello world! Hello world! Hello world! Hello world! Hello world! Einführung in JUDGE 25 Nützliche Moab-Kommandos Nützliche Kommandos zur Abfrage des Job-Status: Kommando msub <job-file> showq [-r] showq -w user=$USER canceljob <job-id> mjobctl -q starttime <job-id> checkjob -v <jobid> mjobctl –-help 27. Oktober 2014 Bedeutung submitiert einen Job listet den Status aller (laufenden) Jobs listet den Status der eigenen Jobs stoppt den Job mit der ID jobid zeigt die geschätzte Startzeit des Jobs mit der ID jobid detaillierte Informationen über den Job jobid listet detaillierte Informationen über das Kommando Einführung in JUDGE 26 Job-Status (llview) 27. Oktober 2014 Einführung in JUDGE 27 Zeitmessung: MPI_Wtime (1) MPI_Wtime(): gibt an, wieviel Zeit (in Sekunden) seit einem (willkürlich festgelegten) Zeitpunkt vergangen ist Die Zeiten sind lokal im rufenden Prozess. Der "Zeitpunkt in der Vergangenheit" bleibt, solange der Prozess lebt, unverändert. Zeitmessung bei parallelen Programmen: Die Zeit, die das parallele Programm benötigt, ist das Maximum der Zeiten, die jeder einzelne Prozess benötigt. Für die Zeitmessung eines MPI-parallelen Programms muss man daher das Maximum der auf allen Prozessoren gemessenen Zeit bestimmen. Damit nicht unterschiedliche Vorlaufzeiten zu einer Verfälschung des Ergebnisses führen, muss außerdem vor der ersten Zeitmessung ein Barrier (MPI_Barrier()) aufgerufen werden 27. Oktober 2014 Einführung in JUDGE 28 Zeitmessung: MPI_Wtime (2) #include <mpi.h> ... double st, ut, time; ... MPI_Barrier(MPI_COMM_WORLD); st = MPI_Wtime(); ... work ... ut = MPI_Wtime()-st; MPI_Reduce(&ut, &time, 1, MPI_DOUBLE, MPI_MAX, 0, MPI_COMM_WORLD); if(my_rank == 0) printf(“time used: %14.8f seconds\n“, time); 27. Oktober 2014 Einführung in JUDGE 29 Visualisierung von Messergebnissen (1) Gnuplot: Generierung von Liniendiagrammen Eingabe z.B.: Tabelle in ASCII-Datei Aufruf (interaktiv): gnuplot Aufruf (batch): gnuplot <cmdfile> Kommandos: plot <file> <opt> help set <opt> <val> ... 64 5.59634645e-05 128 2.05009943e-04 256 8.05962714e-04 512 3.16096324e-03 1024 1.25179816e-02 ... 2.89807795e-05 1.15995877e-04 4.03967744e-04 1.58998877e-03 6.27897843e-03 1.50456908e-05 2.70577730e-05 6.30193390e-05 1.10046938e-04 2.26058415e-04 0.00000000e+00 0.00000000e+00 0.00000000e+00 0.00000000e+00 0.00000000e+00 Weitere Informationen zu Gnuplot: http://www.gnuplot.info/ 27. Oktober 2014 Einführung in JUDGE 30 Visualisierung von Messergebnissen (2) Batch-Datei mit Kommandos: cmdfile # (PostScript output) #set output "kompl.eps" #set terminal postscript eps color solid 12 set xlabel "n" set ylabel "Time (s)" set xrange [2:1024*1024] #set yrange [0:16] set title "Zeitmessung" #set logscale x #set logscale y plot (x**4) with lines lw 1, \ "messung.dat" u 1:2 ti "algo1" with linesp lw 1 pause -1 "Hit return to continue" 27. Oktober 2014 Einführung in JUDGE 31