parallele programmiermodelle - informatik · parallele programmiermodelle (teil 1) k 3.1 – 3.5 -...
TRANSCRIPT
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Parallele Programmiermodelle
ProSeminar: Parallele ProgrammierungSemester: WS 2012/2013
Dozentin: Margarita Esponda
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Einleitung - Kurzer RückblickFlynn'sche Klassifikationsschemata
Unterteilung nach Speicherorganissation
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Einleitung - Themen Heute
- Modelle paralleler Rechnersysteme
- Parallelisierung von Programmen
- Ebenen der Parallelität
- Explizite und implizite Darstellung der Parallelität
- Strukturierung paralleler Programme
Bildquellen falls nicht anders angegeben:T. Rauber, G. Rünger, Parallele Programmierung, eXamen.press, DOI 10.1007/978-3-642-13604-7_3, c Springer-Verlag Berlin Heidelberg 2012,
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Modelle paralleler RechnersystemeGrundlage zur Programmierung sequentielle Rechnersysteme:
Von-Neumann-Architektur (SISD)
Bildquelle: http://academic.udayton.edu/SaverioPerugini/courses/cps346/lecture_notes/introduction.html [Zugriff: 06.11.12; 17:46], Quelle dort: ref. [OSIDP] Fig. 1.1 on p. 9; image courtesy [OSIDP] webpage
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Kriterien zur Unterscheidung paralleler Rechnersysteme
Parallele Rechnersysteme vielfältiger:
Kriterien zur Unterscheidung:
- Maschinenmodelle
- Architekturmodelle
- Berechnungsmodelle
- Programmiermodelle
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Parallele Programmiermodelle
Programmiermodell spezifizieren:
- Parallelität in den Berechnungen
- Ob/wie/in welcher Form Parallelität durch Programmierer zu spezifizieren ist
- Abarbeitung der parallelen Einheit
- Informationsaustausch zw. parallelen Teilen
- Synchronisationsmöglichkeiten
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Parallelisierung von Programmen
Vom sequentiellen zum parallelen Programm (Parallelisierung):
1 Berechnungen zerlegen (Tasks)
2 Zuweisen an Prozesse o. Threads (Scheduling)
3 Abbilden auf phys. Prozessoren (Mapping)
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Parallelität auf Instruktionsebene
Parallelitätspotential in/im Berechnungen/Programm:
- Instruktionsebene (Instruction-Level-Paralism ILP)
→ dynamisch (Hardware) → statisch (Compiler)
Nutzung zum Bsp. bei Schleifeniterationen
→ loop unrolling → Vektoranweisungen
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Konzept Vektoranweisungen
FORTRAN90
→ Schlüssel: Erkennen/Behandeln von Abhängigkeiten
Quelle: Patterson, Hennessy: Computer Architecture, Aufl. 5 S.272
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
DatenabhängigkeitenInstruktionen nur simultan ausführbar wenn keine Datenabhängigkeit:
Flussabhängigkeit(Patterson: data dependences)
Anti-Abhängigkeit(Patterson: Name Dependences- Anti dependence)
Ausgabe-Abhängigkeit(Patterson: Name Dependences- Output dependence)
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Datenabhängigkeit Bsp.Quelle: Patterson, Hennessy: Computer Architecture, Aufl. 5 S.251
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Datenabhängigkeitsgraph
Veranschaulichung:
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Datenabhängigkeiten beheben Bsp. 1
Quelle: Patterson, Hennessy: Computer Architecture, Aufl. 5 Appendix H (H-11)
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Datenabhängigkeiten beheben Bsp. 2
Quelle: Patterson, Hennessy: Computer Architecture, Aufl. 5 Appendix H (H-12)
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Parallele Schleifen in Fortran 1/2
- dopar-Schleife:
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Parallele Schleifen in Fortran 2/2
- doall-Schleife
Schleife: entspricht:
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Implizite Darstellung der ParallelitätAlle Anpassungen eines Programms zur parallelen Ausführung,welche vom Entwickler nicht explizit Dargestellt werden müssen
- Der Entwickler schreibt sequenziellen Code
Umgesetzt in
- Parallelisierenden Compilern
- Funktionalen Programmiersprachen
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Parallelisierende Compiler
Idee: Sequentieller Code wird vom Compiler so umgeschrieben und auf Prozessoren verteilt, dass:
- Abhängigkeiten eingehalten werden- Eine gute Lastverteilung entsteht- Möglichst wenig Austausch zwischen den Prozessoren
stattfindet
Probleme:- Sehr komplexe Aufgabe
→ Bieten oft noch keine guten Ergebnisse
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Parallelisierung FunktionalerProgrammiersprachen
Determinismus macht paralleles Auswerten der Argumente möglich
Probleme:- Argumente haben teils
kein ausreichendes Potential
- Große Rekursionstiefen können zurzu feinen Aufteilung führen → nicht gut auf Prozessoren aufzuteilen
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Funktionale ProgrammierspracheRekursionsanker: foo x 0 = xBeispiel: foo x y = foo (x+1) (y-1) + foo (x+1) (y-1)
foo 3 2 = foo 4 1 + foo 2 3
foo 4 1 = Add 5 0 + Add 5 0
5 5
foo 4 1 = Add 5 0 + Add 5 0
5 5Foo 3 2 = + + +
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Explizite Darstellung der Parallelität
Unterkategorien:
- Explizite Parallelität mit impliziter Zerlegung
- Explizite Zerlegung
- Explizite Zuordnung an Prozessoren
- Explizite Kommunikation und Synchronisation
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Explizite Parallelität mit impliziter Zerlegung
Ermöglichen eine parallele Ausführungohne eine Aufteilung in TasksBeispiel: parallele Schleifen
Vorteile:- Wenig Aufwand für den Programmierer- Einfacherer Compiler möglich
Nachteil:- Sehr Beschränkter Gewinn an Parallelisierbarkeit
Einsatz in vielen Fortran-Erweiterungen
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Explizite Zerlegung
Zerlegung in Task möglich, jedoch keine Zuweisung an Prozessoren
Dadurch höherer Aufwand beim Programmieren,jedoch auch bessere Parallelität
BeispielBSP- Programmiermodell (4.5.2)
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Explizite Zuordnung an Prozessoren
Sowohl explizite Zerlegung in Task,als auch explizite Zuordnung dieser Task. Keine explizite Kommunikation zwischen Prozessoren notwendig
Beispiel: Linda (Koordinationssprache)- Kommunikation über einen Daten-Pool (tuplespace)
Zugriff über Schlüssel mit in/read/out
- Kommunikation wird durch Compiler geregelt- Führt nicht immer zu einer effizienten Implementierung
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Explizite Kommunikation und Synchronisation
Alle Details zur parallelen Ausführung des Programms müssen vom Programmierer explizit angegeben werden.
Vorteil:- Sehr Effiziente Umsetzung möglich- Standardcompiler reichen aus
Nachteil:- Großer Aufwand und Komplexität beim Programmierer
Vertreter sindThread-Programmiermodelle (Kap. 6) undMessage-Passing-Programmiermodelle (Kap. 7)
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Strukturierung paralleler ProgrammeMuster und Prinzipien um Prozesse/Threads zu koordinieren:
- Erzeugung von Prozessen oder Threads
- SPMD und SIMD
- Master-Slave oder Master-Worker
- Pipelining
- Client-Server-Modell
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Erzeugung von Prozessen/ThreadsStatisch Dynamisch
P1
Start
P2 P3 P4
Ende
P1P2
P3
P4
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Erzeugung von Prozessen/Threads
Fork-Join-Konstrukt
Erzeugung eines Kindprozesses, als Kopie des ElternprozessesUnterschiedlicher Code möglich durch Prozessid
Spawn-Exit-Operation im Message-Passing fast gleich (verteilten Adressraum)
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Erzeugung von Prozessen/Threads
Parbegin-Parend- Konstrukt
Aufteilung in mehrere Prozesse innerhalb des Blocks
ParbeginBegin DoProzess1 End;Begin DoProzess2 End;
Parend;
Nach dem Block sind alle Prozesse abgeschlossen
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
SPMD und SIMD
Parallele Ausführung von einer Instruktion oder einem Programmauf verschieden Daten
- Bei SIMD wird jede Instruktion wird synchron auf den Daten ausgeführt- Wird auch als Ansatz zur Datenparallelität bezeichnet
- Bei SPMD wird jedes Programm asynchronausgeführt- Prozesse können an verschieden Stellen im Ablauf sein
→ Synchronisierungen müssen explizit geschrieben werden
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Master-Slave oder Master-WorkerErzeugung der Slaves/Worker kann dynamisch oder statisch erfolgen
Master
Wn...W1 W2
Start
Ende
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Pipelining
Beispiel eines Shellskripts (Übungsaufgabe Alp5)
# use: ./spelling.sh text.txt <Anzahl von Check Prozessen>mkfifo a bjava ue3/Worte $1 >a &for i in {1..$2}do java ue3/Check <a >b &donejava ue3/Analyze <brm a b
Worte
a
Check Check ...
Datei
b
Analyse
Ausgabe
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik
Client-Server-Modell
Bereitstellung eines Dienstes für ein oder mehrere Klienten
Sowohl Parallelisierung der Verarbeitung der Anfragen, als auch Parallelisierung mehrerer Server möglich
- Ähnlichkeit mit dem MPMD-Modell
- Eine gute Lastverteilung ist wichtig
- Kommunikation über verschiedensteProtokolle und Kanäle
Client
Server
Client