Vorgelegt an der Philipps-Universität Marburg

am Fachbereich 12 Mathematik und Informatik

eSkel
The Edinburgh Skeleton Library

Semesterarbeit: Parallele Programmierung

Prof. Dr. Rita Loogen

von
Jens Kohl
kohl@informatik.uni-marburg.de
Wintersemester 2008/2009
Inhaltsverzeichnis

1 Einleitung 3
1.1 Begrifflichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Warum Skelette? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Vergleich 7
2.1 pThreads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 OpenMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 OpenMPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Struktur der Bibliothek 8

3.1 Give, Take und Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 eSkel Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 eigener Struct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 Skelette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Fazit 10

5 Anhang 12
5.1 eMail an Murray Cole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2 Codeänderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
 1 Einleitung

1 Einleitung
Die eSkel1 Bibliothek1 basiert auf der OpenMPI-Bibliothek2 und ist in der Programmiersprache
C geschrieben, andere Sprachen, für die OpenMPI lauffähig ist (C++ und Fortran), werden
nicht unterstützt. Sie wendet sich laut Selbstaussage in erster Linie an erfahrene OpenMPI-
Programmierer.
In dieser Arbeit beschäftige ich mich ausschließlich mit eSkel1. Aktuell wird am Nachfolger,
eSkel2 gearbeitet, welcher zwei weitere Skelette bringen soll: Deal und Haloswap. Bis zum
jetzigen Zeitpunkt wurde aber nur eine sehr frühe Version 0.1 veröffentlicht, die bisher nur
zwei, nämlich Pipeline und Deal, der angekündigten fünf Skelette implementiert.

1.1 Begrifflichkeiten

Bevor im weiteren auf die eSkel Bibliothek eingegangen wird, sollten vorab einige Begriffe
geklärt werden. Den Anfang macht der Begriff der »algorithmischen Skelette«. Hierbei handelt
es sich nach [3] um »useful patterns of parallel computation and interaction [which] can be
packaged up as framework, second order or template constructs«. Also vom Konzept her ähn-
lich den »Design Patterns«-Konzept aus der Softwaretechnik. Mit dem Unterschied, das man in
deklarativen Sprachen wie Haskell algorithmische Skelette eleganter mittels Funktionen höhe-
rer Ordnung implementieren kann. Hierbei stellt das jeweilige Gerüst, welches z.B. als Pipeline
oder als Workpool-Kozenpt implementiert sein kann, die Funktion höherer Ordnung dar. Dieser
Funktion wird in Folge dessen eine »Berechnungsfunktion«, also die konkrete Implementie-
rung, zusammen mit einem eventuell vorhandenem Kostenmodell übergeben.
Im Gegensatz [3] dazu ist die Implementierung algorithmischer Skelette in imperativen Pro-
grammiersprachen auf den ersten Blick nicht ganz so elegant. Ältere Sprachen wie C, die noch
über die Möglichkeit von Zeigern, insbesondere von Funktionszeigern verfügen, können das
Konzept der Funktion höherer Ordnung aber recht gut annähern. Wie auch in der eSkel Bi-
bliothek werden die »Berechnungsfunktionen« wirklich als Funktionen mit einer speziellen
Signatur programmiert. Anschließend wird das jeweilige Skelett parameterisiert aufgerufen.
Dabei werden die Berechnungsfunktionen als Funktionszeiger übergeben. Essentiell sind zum
einen wie gerade erwähnt die Berechnungsfunktionen und eine Eingabe. Je nach Skelett kom-
men einige weitere Parameter wie beispielsweise die Anordnung der Berechnungsfunktionen
(Pipeline-Skelett), Ein- und Ausgabepuffer etc. hinzu.

1 The Edinburgh Skeleton Library

2 OpenMPI [2]

3
 1 Einleitung

calling program

skeleton (pipeline 3-stages)

P P P P P P

P P

stage-1 activity stage-2 activity stage-3 activity

Abbildung 1: Activites

Weiterhin sollten »Activites« (im weiteren Aktivitäten) erläutert werden, weil dieser generische
Begriff von Softwareprojekt zu Softwareprojekt, besonders im OpenSource-Umfeld3 jeweils
unterschiedlich gebraucht wird. Die eSkel Bibliothek verwendet den Begriff der Aktivität ähn-
lich dem Begriff eines Prozesses im Zusammenhang der parallelen Programmierung, also als
Kontext eines Programmes in der Ausführung. Durch die unterliegende OpenMPI-Bibliothek
werden mit dem Start des Programmes aber schon eine feste Anzahl an Prozessen generiert und
ausgeführt. Alle Prozesse in einem MPI-Kommunikator rufen kollektiv das zu verwendende
Skelett auf. Je nach der zugrundeliegenden Semantik des Skelett werden die aufrufenden Pro-
zesse umorganisiert bzw. virtuell zu Aktivitäten gruppiert. Beim Pipeline-Skelett für 3 Stages
wird für jede Stage eine Aktivität generiert und die unterliegenden Prozesse gleichmäßig den
Aktivitäten zugeordnet.
Die eSkel Bibliothek bietet für die Kommunikation innerhalb der Aktivitäten drei eigene Funk-
tionen:

mycomm Die Aktivitäten werden mittels MPI-Kommunikatoren realisiert. Jede Aktivität er-
zeugt einen neuen MPI-Kommunikator. Die Funktion mycomm(void) liefert den passenden
MPI-Kommunikator zurück.

mycommsize Liefert die Größe eines Kommunikators zurück, also die Anzahl der mit diesem
Kommunikator assoziierten Prozesse.

3 vgl. Google Androids Activity-Konzept [7]

4
 1 Einleitung

myrank Neben der schon von MPI bekannten Rank-Funktion, stellt eSkel eine weitere Rank-
Funktion zur Verfügung welche den eigenen Rank innerhalb einer Aktivität zur Verfügung stellt.
Dies ist insbesondere bei den *1for1-Skeletten essentiell, da dort derjenige Prozess mit dem
Rang 0 meist verwaltende Aufgaben übernimmt (z.B. ein Farmer-Prozess).
Allen drei Funktionen ist gemeinsam, dass sie ausserhalb eine Aktivität stets den
MPI_WORLD_COMM Kommunikator zurückliefern.

1.2 Warum Skelette?

Algorithmische Skelette sind typische Muster der parallelen Programmierung. Aus dieser Fest-
stellung ergibt sich schon eine gewisse Inflexibilität gegenüber weniger abstrahierter Program-
mierung. Es kann also sein, das für einen speziellen Fall, keins der bisher entwickelten Skelette
die Anforderungen erfüllt. Die Nichterfüllung der Anforderungen führt im schlechtesten Fall
zu einem Mehraufwand bei der Berechnung und/oder der Kommunikation. Insbesondere die
mehrfache Ausführung redundanter Berechnungen und Kommunikation dürfte zu einem Lauf-
zeitverlust führen.
Nichtsdestotrotz bieten Skelette auch viele Vorteile. So sind die bisher entwickelten Skelette
aus der Realität der parallelen Programmierung entwickelt worden. Das Master-Worker-Prinzip
ist ebenso intuitiv wie es auch oft anzutreffen ist. Aus diesem Prinzip abstrahierte man das
Workpool-Skelett, welches in eSkel mehr oder weniger als Farm-Skelett auftritt.
Der erste Vorteil einer Skelettsammlung ist für den Programmierer offensichtlich: Er muss sich
nicht um die Kommunikation und die Organisation der Prozesse kümmern. Er muss sich le-
diglich im Vorfeld Gedanken darüber machen, welche Struktur sein Problem hat und welches
Skelett am ehesten dazu passt. Allerdings sei hier angemerkt, dass durch die Struktur der Ske-
lettbibliotheken das Wechseln eines Skelettes im Nachhinein mit wenig Aufwand möglich ist.
Stellt sich also heraus, dass die anfänglichen Gedanken über das Skelett falsche Annahmen
beinhalteten, so ist ein Wechsel mit ein wenig Aufwand auch dann noch möglich, wenn das
Programm bereits mit dem ursprünglichen Skelett bereits lauffähig ist.
Ein weiterer Vorteil, der für den Programmierer nicht so offensichtlich ist wie der erste, ist die
Erfahrung die bei der Entwicklung der Skelette bereits vorhanden war. Parallele Programmie-
rung ist für die meisten Entwickler ein relativ neues Betätigungsfeld. Bis auf wenige Ausnah-
men lernen fast alle Programmierer ihr Handwerk mit sequentieller Programmierung, bis vor
kurzem sogar noch auf sequentiellen Maschinen. Diese Situation hat sich mit der Einführung
von Dual- respektive Multicore-Maschinen zwar geändert, doch die Ausbildung der Program-
mierer ist im wesentlichen noch sequentiell.

5
 1 Einleitung

Aufgrund der sequentiellen Ausbildung ist der Erfahrungsstand eines Programmierers gerade in
den Anfängen seiner ersten Versuche in der parallelen Programmierung gering bis nicht vorhan-
den. Gerade wenn man sich die parallele Programmierung in Java mit dem dahinter liegendem
Multithreading ansieht. Dort wird insbesondere die Interprozesskommunikation soweit es geht
vermieden, so dass keine »Race conditions« entstehen können.
Die fehlende Erfahrung ist aber gerade bei der parallelen Programmierung das größte Problem.
Viele der möglichen Fehler muss man erst einmal begangen haben um sie in der Zukunft zu
vermeiden. Denn die meisten der Fehler sind nicht intuitiv und es wird eine Weile brauchen um
nachvollziehen zu können, was genau in einer speziellen Situation falsch gelaufen ist, um zu
erkennen warum dies zu einen unerwünschten Verhalten im Ganzen führt.
Genau an dieser Stelle setzen die algorithmischen Skelette an. Denn Skelette werden in aller Re-
gel von erfahrenen Programmierern auf dem Gebiet der parallelen Programmierung entwickelt.
Eben diese Programmierer haben die eben angesprochenen Fehler mehr oder weniger alle be-
reits erlebt. Das Wissen um diese Fehlermöglichkeiten wurde bei der Entwicklung der Skelette
so gut es geht berücksichtigt. »Algorithmische Skelette« stellen die in der Softwareentwicklung
hochgehaltenen »Best Practises« dar.
An dieser Stelle soll dann auch der dritte und letzte Vorteil nicht verschwiegen bleiben: die
Performance. Zu Anfang dieses Abschnittes wird zwar auf die Inflexibilität der Skelette und
des damit verbundenem, potenziellem Laufzeitabfalls hingewiesen. Doch gilt der potenzielle
Laufzeitabfall nur falls kein passendes Skelett gefunden werden kann und man es trotzdem mit
jenem unpassendem Skelett versucht. Wie bisher ausgeführt, leiten sich die bestehenden Ske-
lette aus realen Problemen ab, so dass es unwahrscheinlich ist, das man in eine Situation gerät,
in der ein bereits entwickeltes Skelett nicht zur Struktur des eigenen Problems passt. Sollte der
Fall trotzdem eintreffen so kann aber immer noch versucht werden, ein eigenes Skelett zu entwi-
ckeln und es der Allgemeinheit wiederum zugänglich zu machen. Wird nun also ein passendes
Skelett gefunden, so wird durch die im Skelett enthaltene Erfahrung meist ein besseres Laufzeit-
verhalten erreicht, als wenn ein eher unerfahrenerer Programmierer sich ohne die Verwendung
von Skeletten selbst an die Parallelisierung seines Problems bzw. Algorithmus macht.

6
 2 Vergleich

2 Vergleich
Bisher existierende Bibliotheken sind historisch gewachsen und abgelöst worden. Anfängli-
che Bibliotheken wie die pThreads-Library konzentrierte sich nur auf die Threaderzeugung auf
»shared memory« Systemen, später kamen mit MPI-Bibliotheken wie OpenMPI der Aspekt der
»distributed memory« Systeme hinzu.
Es folgt ein kurzer Vergleich darüber was skelettbasierte Programmierung gegenüber bestehen-
den Bibliotheken leisten kann.

2.1 pThreads

Die Native POSIX Threading Library kurz pThreads hat als eines seiner Kernziele die güns-
tigen Erzeugungskosten für Threads. Im Vergleich zur Skelett-Programmierung ist der Vor-
teil von pThreads vor allem die gezielte Parallelisierung. Da die jeweilige Parallelisierung mit
allen zugehörigen Locks von Hand programmiert werden muss, ergeben sich hier potenziell
Geschwindigkeitsvorteile. Ein großer Nachteil dieser Herangehensweise ist bei fehlender Er-
fahrung mit Parallelisierung potenziell schlechter Code, welcher im schlimmsten Fall zu nicht
funktionierenden Programmen oder einem Slowdown führen kann.

2.2 OpenMP

Vorangehende Nachteile pThreads haben zur Entwicklung von OpenMP geführt. OpenMP selbst
basiert auf Direktiven als Kommentar im Code. Es sind keine direkten Funktionsaufrufe mehr
nötig, so dass dem Compiler die Entscheidung überlassen wird eine Direktive zu beachten oder
sie zu ignorieren. OpenMP selbst erzeugt pThreads-Code, welcher wie bislang vom Compiler
übersetzt wird. Einige der Nachteile von pThreads werden damit schon vermieden, allerdings
ist es immer noch leicht möglich mit seinem Code ein Laufzeitverhalten zu erzielen welches
auf Mehrprozessorsystemen unter deis eines Einzelprozessorsystems fällt. Dies vor allem des-
wegen, da es ohne weiteres möglich ist eine sequentielle Ausführung mit dem Mehraufwand
der Verwaltung von Mutal-Exclusions zu erzeugen. Im direkten Vergleich hat hier die Skelett-
Programmierung den Vorteil, das die implementierten Skelette quasi eine Art Best-Practise dar-
stellen. Entwickler der Skelette haben auf dem Gebiet der Parallelisierung viel Erfahrung und
können ihren Code eventuell höher optimieren.

7
 3 Struktur der Bibliothek

2.3 OpenMPI

Die Motivation, welche zur Entwicklung der MPI-Bibliotheken geführt hat, war das pThreads
und OpenMP auf »shared memory« Systeme beschränkt sind. Grundlegend unterscheidet sich
die Implementierung von OpenMPI von den bisher genannten Bibliotheken also im Rückgriff
auf »Message Passing« um Parallelität auf »distributed memory« Systemen realisieren zu kön-
nen. Besonders durch die Kommunikation zwischen den einzelnen Systemen tun sich allerdings
neue Fallstricke auf. Auch hier können Skelette punkten, da wieder die Erfahrung der Skelett-
entwickler dazu führt, dass viele der möglichen Fehler gar nicht erst begangen werden.

3 Struktur der Bibliothek

Das eSkel1 API reference manual [5] beschreibt den Aufbau der eSkel Bibliothek. Grundsätz-
lich werden drei verschiedene Skeletttypen unterschieden:

• Farm Skelette
– Farm
– Farm1for1
– SimpleFarm
– SimpleFarm1for1

• Pipeline Skelette
– Pipeline
– Pipeline1for1

• Butterfly Skelett

Zusätzlich zu den Implementierungen der einzelnen Skeletttypen und den eingangs besproche-
nen Funktionen zum Verwalten der Aktivitäten stellt die eSkel1 Bibliothek drei weitere Funk-
tionen für die Kommunikation zwischen einzelnen Aktivitäten bereit: Give, Take und das allge-
meinere Exchange.

3.1 Give, Take und Exchange

Für parallele Algorithmen ist die Kommunikation mit anderen Prozessen, bei eSkel abstrakter:
Aktivitäten, von essentieller Natur. Im Farm-Skelett ist es offensichtlich, dass sofern es einen
dezidierten Farmer gibt, mit ihm kommuniziert werden muss. Gibt es Arbeit? Arbeit anfordern,

8
 3 Struktur der Bibliothek

Ergebnisse zurücksenden, etc. Für diese Art der Interprozesskommunikation stellt eSkel gene-
rische Funktionen bereit. Insbesondere Give und Take. Exchange hingegen ist eine Zusammen-
fassung der beiden vorangegangenen Funktionen und wird nur bei paarweiser Kommunikation
benötigt, wie z.B. beim Butterfly-Skelett.
Je nach Lokalität der Daten werden sowohl Give als auch Take kollektiv im Fall von globalen
Daten bzw. im Fall von lokalen Daten vom Prozess mit dem Rank 0 aufgerufen. Die Unterschei-
dung der Lokalität treffen die Funktionen aufgrund des Datenmodells auf dem sie arbeiten.

3.2 eSkel Datenmodell

Das »eSkel Data Model« kurz: eDM unterteilt sich in zwei Teile, zum einen »eDM atom« und
zum anderen »eDM collection« wobei letzteres, wie bereits dessen Namen vermuten lässt, ei-
ne Ansammlung von eDM Atomen ist. Allerdings unterscheiden sich ihre Anwendungsfälle
grundsätzlich. So werden eDM Atome in eSkel nur zum Datentransfer zwischen der Skelett-
funktion und den beteiligten Aktivitäten genutzt. eDM Collections hingegen zum Datentransfer
zwischen aufrufendem Programm, also dem Stück Code welcher den Skelettaufruf macht, und
den Skeletten selbst.
Sowohl eDM Atom als auch eDM Collection unterscheidet den so genannten »Spread« der Da-
ten in einen lokalen und einem globalen Spread. Dies ist vor allem wichtig für die Aufrufe von
Give und Take, die Anhand des Spreads zwischen Kollektiv- und Einzelaufruf unterscheiden.

3.2.1 eigener Struct

Daten werden an eSkel immer über einen selbst definierten Struct ausgetauscht, dessen Aufbau
sehr einfach gehalten ist:
typedef struct {
void ∗ d a ta ;
int len ;
} eSkel_atom_t ;
Er besteht lediglich aus einem Zeiger auf die Daten und einem Feld für die Länge der dort
gespeicherten Daten. Diese Konstruktion war nötig, da manche der Skelette implizit Give /
Take Operationen durchführen, so dass Daten leicht an Aktivitäten im Sinne von generisch als
Parameter oder Rückgabetyp weitergereicht werden können.

9
 4 Fazit

3.3 Skelette

Wie auf Seite 8 aufgelistet ergibt sich durch die Benennung der Skelette eine flache Hierarchie.
Es werden die drei Grundtypen: Farm, Pipeline und Butterfly unterschieden. Außerdem gibt es
bis auf vom Butterfly-Skelett jeweils *1for1-Typen. Eine Besonderheit gibt es noch beim Farm-
Skelett und zwar die thread-sichere Version des Farm-Skelettes in der SimpleFarm-Variante.
Diese Variante ist intern sequentiell implementiert, so dass sie auch in nicht-thread-sicheren
MPI-Umgebungen lauffähig ist.
Die *1for1-Typen der Skelette sind Einschränkungen ihrer namensgleichen Pendants. Sie set-
zen voraus, dass jede Aktivität (Farm- bzw. Workerprozess, Pipelinestage, Node, etc.) für jede
Eingabe eine Ausgabe liefert und auch eine Eingabe erfordert. In solchen Skeletttypen sind
Give / Take-Aufrufe immer implizit und der Programmierer hat sich somit nicht um die Kom-
munikation im Detail zu kümmern, außer dass er für jede Eingabe eine Ausgabe mit seinem
Algorithmus liefert.
Umgekehrt dazu sind die Skeletttypen ohne das 1for1-Suffix etwas aufwändiger in ihrer Pro-
grammierung. Diesen Mehraufwand bekommt man aber in Form gesteigerter Flexibilität zu-
rück. Der besondere Charakter dieser Skeletttypen ist das sie weder Ein- noch Ausgabe liefern
müssen, aber auch mehrere Ein- bzw. Ausgaben bearbeiten können. Denkbar wäre z.B. in einer
Pipeline eine Stage, die Zufallszahlen generiert – hier gäbe es keine Eingabe aber eine wie auch
immer detailliert geartete Ausgabe.

4 Fazit
Löst eSkel1 die Probleme für die es entwickelt worden ist? Ja und nein. Auf der theoretischen
Seite hauptsächlich schon. Es bewahrt den unerfahrenen Programmierer vor all zu offensicht-
lichen Stolperfallen und führt das Konzept der algorithmischen Skelette in eine »low-level«
Sprache wie C ein. Das sogar recht elegant durch die Ausnutzung von Funktionszeigern. Auch
die Abstraktion der Interprozesskommunikation ist mit dem Herunterbrechen auf zwei bzw. drei
Funktionen, namentlich Give, Take und Exchange gut gelungen.
Allerdings steht auf der anderen, der praktischen Seite, einer Verwendung unter realen Bedin-
gungen einiges entgegen. So schreibt M. Cole (Seite 12), dass keine detaillierte Analyse des
Codes stattgefunden hat und er weiterhin vermutet, dass die eSkel1 Bibliothek einige Spei-
cherlecks aufweist. Da parallele Programme bis heute erst dann eingesetzt werden, wenn die
Leistung der sequentiellen Programme nicht mehr ausreicht. So ist davon auszugehen, dass
Speicherlecks in diesem Bereich nicht toleriert werden.

10
 4 Fazit

Ein weiterer Grund, der gegen die Verwendung von eSkel1 spricht ist die Tatsache, dass der
Aufruf der Skelette viel zu viele Parameter erfordert. Viele Parameter tragen nicht zur Über-
sichtlichkeit bei und führen oft zu Fehlern. Allerdings kann man mit mehr Parametern eine
gewisse Flexibilität wahren. Allerdings hat die Softwaretechnik für derartige Probleme schon
Lösungsansätze gefunden, so wäre ein weiteres Struct zu Übergabe von Konfigurationsparame-
ter für alle Skelette denkbar. Dies hätte zwei große Vorteile:

• Durch die Verwendung eines Konfigurations-Structs würden die Parameter bei ihrer Ver-
wendung beschrieben (zum Beispiel config->spread = SPGLOBAL). Dies hat vor allem
den Vorteil, dass man sich bei der Programmierung im wesentlichen auf den erzeugten
Code, statt auf die Recherche der richtigen Parameter in der API Reference [5] sparen
könnte.
Eine grundlegende Auseinandersetzung mit der Einführung in die spezielle Vorgehens-
weise mit eSkel1 erspart man sich dadurch allerdings auch nicht. Hier leistete das Tutorial
[6] aber gute Dienste.

Da ein Struct allerdings nicht auf alle Skelette passen kann (im Vergleich zu den jewei-
ligen Farm- und Pipelinetypen, erwartet das Butterfly-Skelett wesentlich weniger Para-
meter), sollten nicht genutzte Paramater auf Standardwerte gesetzt werden. Die jeweilige
Implementierung der Skelette greift dann nur auf die für sie wichtigen Parameter zu und
ignoriert alle restlichen.

• Standardwerte könnten schon beim Aufruf von eSkel_Init gesetzt bzw. für einzelne Ske-
letttypen angepasst werden. So würden auch Einsteiger ohne großes Nachdenken schon
einmal loslegen können. Finetuning kann dann im weiteren Verlauf der Programmierung
erfolgen.

Auffallend war, dass die Lektüre des Tutoriums [6] und der API Referenz [5] nicht zum Ver-
ständnis der vom Farm- und Pipelineskelett geforderten multiciply und spread Parameter bei-
getragen haben. Erst nach dem Lesen des Papers »Bringing Skeletons out of the Closet« [4]
erschloss sich mir deren Bedeutung.
Alles in Allem scheint sich bei dem Vorhaben skelettbasiert in C programmieren zu wollen
die Auseinandersetzung mit der Konkurrenzbibliothek Muesli [1] zu lohnen. Beim flüchtigen
Überfliegen der Projekthomepage macht es den Anschein, dass im Gegensatz zu eSkel1 und 2
dort die Weiterentwicklung nicht stehen geblieben ist.

11
 5 Anhang

5 Anhang

5.1 eMail an Murray Cole

Anfrage Hello Mr. Cole,

I’m a computer science student from Marburg, Germany. I’m writing an essay within my paral-
lel programming lecture held by Prof. Loogen. My topic is your eSkel library. I’m wondering
what the current state of the development is, since the last update of the website and therefore
eSkel2 was back in January 2005 with 3 skeletons left unimplented. Was there any kind of
further development after the last update?
I’m also interessted if there are any real-world case studys besides the mandelbrot example
which was described in the eSkel1 manifesto. Is there any experience with the stability of the
library in regard to memory leaks etc.?

Antwort Hi Jens.
What you find at http://homepages.inf.ed.ac.uk/abenoit1/eSkel/ was essentially how
eSkel was left. The multiple baseline stereo application described there was really implemented.
There was no analysis of space leaks (and I expect that the implementation is full of them!).
You might also want to look at the work of my former Research Assistant Greg Yaikhom - see
the section labelled »Skeleton programming library with dynamic scheduling support« towards
the bottom of http://users.cs.cf.ac.uk/G.Yaikhom/.
As an extension of the ENHANCE project, Greg implemented this software, which was related
to, but not really an extension of, eSkel.

5.2 Codeänderungen

In der originären Version von eSkel1 wie sie von der Projektseite heruntergeladen werden kann,
befindet sich ein Fehler. Dieser Fehler führt in den Standardeinstellungen des GCC dazu, dass
es beim Kompilieren von eSkel zu einem Fehler kommt. Um eSkel auf den Rechnern der Uni-
versität zum Laufen zu bekommen, ist eine Änderung an zwei Dateien notwendig.
Im Unterverzeichnis Examples liegen zwei Dateien butterflyhqs.c und exchangehqs.c, in beiden
Dateien muss in Zeile 167 exit() ein Parameter übergeben werden, das kann ein beliebiger Inte-
ger sein. »0« bietet sich hier an. Nach diesen Änderungen laufen die Beispiele auf den von mir
genutzten Rechnern.

12
 Literatur

Literatur
[1] The Münster Skeleton Library Muesli http://www.wi.uni-muenster.de/pi/
forschung/Skeletons/index.html, Abruf: 03.02.2009.

[2] OpenMPI, http://www.open-mpi.org, Abruf: 18.02.2009.

[3] M. Cole A. Benoit. eSkel library home page, http://homepages.inf.ed.ac.uk/

abenoit1/eSkel/, Abruf: 18.02.2009.

[4] M. Cole. Bringing Skeletons out of the Closet, 2002.

[5] M. Cole. The edinburgh Skeleton library API reference manual, July 15, 2002.

[6] M. Cole. The edinburgh Skeleton library Tutorial introduction, July 15, 2002.

[7] Google. Android Activity-Konzept: http://developer.android.com/reference/

android/app/Acitivity.html, Abruf: 18.02.2009.

13