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: 0E  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.fz­juelich.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.fz­juelich.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.fz­juelich.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.fz­juelich.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.fz­juelich.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 job­id
zeigt die geschätzte Startzeit des Jobs
mit der ID job­id
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