eSkel – edinburgh Skeleton library

Präsentation zum Thema: "eSkel – edinburgh Skeleton library"—  Präsentation transkript:

1 eSkel – edinburgh Skeleton library
Kurz (!) nochmal warum parallele Programmierung überhaupt interessant Parallel? Klar Intel Duo und co – natürlich NICHT! Höchsten weiteres Anzeichen; Dagegen: Viel Forschung mit Simulationen (Auto Crashtests, feine Netze über Karosserie) Schnellste System der Welt: „IBM BlueGene/L System“ in Kalifornien Über 280 Trillionen Berechnungen pro Sekunde Über Prozessoren!! Titel erklären: edinburgh skeleton library Wie passt das in den Kontext? Parallele Programmierung schwierig; Skelette ein Ausweg. Überzeugt nach dem Vortrag. Parallele Programmierung mit Skeletten Mai 2007 Seminararbeit Ingo Dyrbusch

2 Skelett-Programmierung
Inhalt Grundlagen Was ist ein Skelett? Ziele von eSkel Daten- vs. Funktionale Parallelität Basiselemente von eSkel Prozesse & Aktivitäten Datenmodell eSkel - Skelette Task-Farm Pipeline Divide & Conquer Skelett - Topologien Neuerungen in eSkel 2 Zusammenfassung und Ausblick Parallele Programmierung komplexes Thema und erstmal einiges an Grundwissen notwendig. Trotzdem ganz kurz anhand eines Beispiels denn Sinn dieser Ausarbeitung bevor wichtige Grundlagen eingeführt werden

3 Was ist ein Skelett? Beispiel „load-balancing“ (Task-Farm):
Von der unstrukturierten zur strukturierten Programmierung Beispiel „load-balancing“ (Task-Farm): MPI: Simplse Framework >> Universell, können unendlich komplexe Interaktionen beschreiben >> Kleines, simples Set an Operationen Schwierig bei statischer Betrachtung Muster im Gesamten zu erkennen Schwierig Optimierungen auf grober Ebene. Übliche Programmgerüste bei der parallelen Programmierung („Standardaufgabe“: verteilung von Aufgaben) Bild erklären: Links Aufgaben, unten Aktivitäten die darauf ausgeführt werden, rechts Ergebnisse Farmer verteilt, weil unterschiedlich komplexe Aufgaben Struktur in Code umzusetzen schon sehr aufwändig und komplex  Zeitaufwand, Fehleranfällig, nicht portierbar, etc. (siehe Ausarbeitung) Daher: Idee so eine Art Templates zu schaffen: Name: „Skelett“ (also nichts anderes als ein Programmgerüst, welches man nutzen kann) „Das im Hinterkopf halten – da wollen wir hin. Jetzt das Thema in den Kontext einordnen und Grundlagenwissen schaffen!“ Grafik: [Co04]

4 eSkel: Konzeption & Ziele
Anforderungen Ansprechend für MPI Programmierer Schnelle Einarbeitung Auszahlung in kurzer Zeit Folgerungen Bibliothek Basis: C/MPI. Im Gegensatz zu funktionalen oder neuen parallelen Programmiersprachen  keine neue Programmiersprache Kein neues Framework, nicht zu komplex Zwei Dinge interessant: schnell Ergebnisse erzielen & Vorteile sehen (Performance-Verschlechterung deutlich geringer als Arbeits-Ersparnis) Skelette = kollektive Operationen (gemeinsame Operationen vgl. Julian MPI!!), die oft auftretende Berechnungs- oder Kommunikationsmuster kapseln. Alle eSkel Aufrufe operieren im Kontext eines laufenden MPI-Programms  Direkte Nutzbarkeit von MPI-Operationen auf allen Ebenen  ad-hoc Parallelität!!

5 Paralleles Arbeiten Daten- und Funktionale Parallelität
Beispiel Landschaftspflege Funktionale oder Taskparallelität vs. Datenparallelität Grafik: [Qu04, S. 11]

6 Basiselemente von eSkel
Prozesse und Aktivitäten Aktivitäten Prozesse Zusammenbasteln von gängigen Strukturen mit Aktivitäten Zuordnung von Prozessen zu Aktivitäten Grafik: [Qu04, S. 11]

7 Basiselemente von eSkel
Datenmodell eDM - Atom Tripel: Zeiger, Länge, Typ (vgl. MPI) Spread (= Ausdehnung) eDM - Collection Bündelung von eDM - Atomen. Spread: gibt den Daten eine gewisse Semantik. (Bsp.: drei Prozesse in einem Skelett enthalten Daten. Nur durch den Spread kann festgelegt werden, dass die Daten zusammengehören und z.B. die Reihenfolge entscheidend ist [Bsp.: Bild]) Länge vs. Multiplicity

8 eSkel - Skelette Skelett-Familie „Task-Farm“ Ein Ergebnis pro Atom
Expliziter Informationsaustausch Impliziter Farmer Farm1for1 Farm Expliziter Farmer SimpleFarm1for1 SimpleFarm Jetzt geht es in den interessanten Teil des Vortrags so genannte Skelett-Familien (in eSkel 1) Explizit: Programmierer sieht Farmer & kümmert sich um seine Programmierung Interaktionsart als Kategorisierung schonmal im Hinterkopf behalten Grafik vgl: [PK05, S. 3]

9 eSkel - Skelett: Farm1for1
Ein Ergebnis pro Atom; impliziter Farmer void Farm1for1(int nw, eSkel atom t * worker (eSkel atom t *), int col, void *in, int inlen, int inmul, spread t inspr, MPI Datatype inty, void *out, int outlen, int *outmul, spread t outspr, MPI Datatype outty, int outbuffsz, MPI Comm comm); void Farm1for1 ( int nw, eSkel_atom_t * worker (eSkel_atom_t *), int col, void *in, int inlen, int inmul, spread_t inspr, MPI_Datatype inty, void *out, int outlen, int *outmul, spread_t outspr, MPI_Datatype outty, int outbuffsz, MPI_Comm comm) Erst: warum 15 Parameter? Weil MPI Basis und maximale Flexibilität (Erinnerung an Ziele!) Col: Erinnerung an Zuweisung mehrerer Prozesse zu einer Aktivität (Landschaftspflege & Personen) [Rang: MPI, Zuordnung über eine Nr.] Typinformationen: Spread und MPI-Datentyp Communicator (Kontext) Zuordnung von Prozessen zu Aktivitäten Anzahl der Worker Worker-Aktivität (Zeiger auf C-Funktion) Input eDM-Collection & Typinformationen Output eDM-Collection, Typinformationen & Output-Buffer

10 eSkel - Skelett: Farm Expliziter Informationsaustausch; impliziter Farmer void Farm ( int nw, void worker (void), int col, void *in, int inlen, int inmul, spread_t inspr, MPI_Datatype inty, void *out, int outlen, int *outmul, spread_t outspr, MPI_Datatype outty, int outbuffsz, MPI_Comm comm) Flexibler! Beispielsweise 2 Ergebnisse pro Eingabe (Wurzel ziehen!?) Oder Filter! Nicht unbedingt eine Ausgabe! Ausführlich: Give() & Take() Grafik vgl: [PK05, S. 3]

11 eSkel - Skelett: SimpleFarm
Expliziter Informationsaustausch; expliziter Farmer void SimpleFarm( int nw, void worker (void), int col, void *in, int inlen, int inmul, spread_t inspr, MPI_Datatype inty, void *out, int outlen, int *outmul, spread_t outspr, MPI_Datatype outty, int outbuffsz, MPI_Comm comm) „Philosophie“: implizit bekommt der erste Prozess, der die Fkt aufruft, die Rolle des Farmers; alle anderen „Ein-Prozessor-Worker-Aktivitäten“ Trotzdem gerade die Möglichkeit der expliziten Formulierung eines eigenen Farmers vorteilhaft! SimpleFarm1for1 nicht näher erläutert

12 eSkel - Skelett: Pipeline
Expliziter Informationsaustausch void Pipeline ( int ns, void (*stages[])(void), int col, spread_t spr[], MPI_Datatype ty[], void *in, int inlen, int inmul, void *out, int outlen, int *outmul, int outbuffsz, MPI_Comm comm) Spread und Datentyp hier in Form von Arrays, da theoretisch von Aktivität zu Aktivität verschieden Give() und Take() je nach dem wo aufgerufen unterschiedliche Wirkung Grafik vgl: [Tut02, S. 3]

13 Pipeline & Parallelität
Parallelitätsgedanke So wie man sich das normalerweise vorstellt: eins nach dem anderen wenn nun jeder Arbeitsschritt von unterschiedlichen Maschinen ausgeführt wird…  unterschiedliche Maschinen = mehrere Prozessoren 2 Autos nicht in n=8 sondern n=5 Grafik: [Qu04, S. 13]

14 eSkel - Skelett: Butterfly
Ein Divide & Conquer Skelett Für Divide & Conquer Algorithmen mit folgenden Eigenschaften: Alle Aktivitäten in der Teilungsphase Anzahl der Prozesse zu Anfang Potenz von 2 und halbiert sich von Level zu Level Interaktionen zwischen Prozessoren treten paarweise auf – in der Form, dass die Dimensionen eines Hypercubes heruntergebrochen werden. Einschränkungen hervorheben

15 eSkel - Skelett: Butterfly
Beispiel Hyperquicksort – Daten irgendwie über alle Prozesse verteilt Grafik: [Co04]

16 eSkel - Skelett: Butterfly
Grafik: [Co04]

17 eSkel - Skelett: Butterfly
Im letzten Schritt normaler Quicksort in jedem Prozess. Danach: In Prozessen und insgesamt (in Rangfolge der Prozesse) sortiert. Grafik: [Co04]

18 eSkel - Skelett: Butterfly
void Butterfly ( int nd, void level(void), MPI_Datatype ty, MPI_Comm comm) nd Anzahl der Level (entspricht Logarithmus zur Basis 2 von der Anzahl der zugeordneten Prozesse – im Beispiel eben 3) level Zeiger auf die Funktion, die in jeder Aktivität aufgerufen wird Exchange()

19 Skelett - Topologien Theoretisch beliebig komplexe Verschachtelungen möglich „Nesting“; z.B. Pipeline – unterschiedlich komplexe Aktivitäten: Replikation einzelner Aktivitäten Grafik vgl: [PK05, S. 3]

20 Neuerungen in eSkel 2 ... Skelette
Pipeline, Deal, (Farm, HaloSwap, Butterfly) Deal: ZIEL: Flexibler, generischer! Alle 5 bereits in der Spezifikation, nur 2 implementiert; Deal: zyklische Zuteilung der Aufgaben (homogene Aufgabensruktur) Vorteil: Reihenfolge leibt erhalten ... Grafik vgl: [BCGH205, S. 2]

21 Neuerungen in eSkel 2 Datenmodell Neu: eDM-Molekül
Interaktionsart explizit: Interaction mode IMPL, EXPL, DEV Verschachtelungsart explizit: Data mode BUF, STR. eDM-Molekül – Austausch mehrerer eDM-Atome in einer einzigen Interaktion (benötigt z.B. HaloSwap – trotzdem alle Signaturen geändert: Konsistenz) Neuer Parameter; Implicit, explizit, devolved; vgl. „1for1“ Data mode: vorher immer transient – jetzt auch persistent möglich. Buffer mode, stream mode Hier unbedingt auf das dynamische Nesting eingehen!!

22 Neuerungen in eSkel 2 Molekül, Interaktions- und Verschachtelungsart am Beispiel der Pipeline-Signatur void Pipeline ( int ns, Imode_t imode[], eSkel_molecule_t * (*stages[])(eSkel_molecule_t *), int col, Dmode_t dmode, spread_t spr[], MPI_Datatype ty[], void *in, int inlen, int inmul, void *out, int outlen, int *outmul, int outbuffsz, MPI_Comm comm)

23 Zusammenfassung Skelette als sinnvolle Grundlage für die parallele Programmierung Grundlegende Forschungsergebnisse: Verschachtelungs- & Interaktionsmodi Einarbeitungszeit ~ 1h. 1 Stunde: natürlich provokativ, dennoch für geübten MPI-Programmierer wohl kein Problem (Skelette: logische Fortführung ihrer Gedanken)

24 Ausblick Effizienz der Implementierungen leidet nachgewiesenermaßen nur wenig eSkel leider noch im Stadium eines Prototyps In Planung: Mehr Demo-Anwendungen Interne Optimierungen Ausweitung des Skelett-Angebots Vereinfachte API (evtl. neue Basis: JAVA-MPI?!). eSkel ist zurzeit nur als Forschungsprojekt zu verstehen

25 6. 14 Verwechsle nie das Modell mit der Realitaet
6.14 Verwechsle nie das Modell mit der Realitaet! (Merksatz: Versuche nie die Speisekarte zu essen). 6.22 In der Wissenschaft gibt es keine Antworten, nur Querverweise.

26 Quellennachweis [BCGH205] A. Benoit, M. Cole, S. Gilmore, J. Hillston: Using eSkel to implement the multiple baseline stereo application, Proceedings of ParCo, Malaga, 2005. [Co04] M. Cole: Presentation, School of informatics, Edinburgh, 2004. [PK05] M. Poldner, H. Kuchen: On Implementing The Farm Skeleton, Proceedings of HLPP, Werwick, [Qu04] M. Quinn: Parallel Programming in C with MPI and OpenMP, McGraw-Hill, 2004. [Tut02] M. Cole: The edinburgh Skeleon library - Tutorial introduction, 2002, URL: Abrufdatum: 24. April 2007.

27 „Spread“ Quelle: [Co04, S. 395]