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 131.000 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

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

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]

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!!

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

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]

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

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]

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

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]

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

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]

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]

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

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

eSkel - Skelett: Butterfly Grafik: [Co04]

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

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()

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]

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]

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!!

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)

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)

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

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.

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, 2005. [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: http://homepages.inf.ed.ac.uk/abenoit1/eSkel/, Abrufdatum: 24. April 2007.

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