parallele programmiermodelle - informatik · parallele programmiermodelle (teil 1) k 3.1 – 3.5 -...

34
Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik Parallele Programmiermodelle ProSeminar: Parallele Programmierung Semester: WS 2012/2013 Dozentin: Margarita Esponda

Upload: ngonhan

Post on 27-Aug-2019

222 views

Category:

Documents


0 download

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

Parallele Programmiermodelle (Teil 1) K 3.1 – 3.5 - Tobias Kranz, Torsten Hain Institut für Informatik

Danke