Scheduling von WITH-loops in SAC

Transkript

1 Scheduling von WITH-loops in SAC Studienarbeit Borg Enders Lehrstuhl für Rechnerorganisation am Institut für Informatik und Praktische Mathematik der Christian-Albrechts-Universität zu Kiel Juli 2001

2 Inhaltsverzeichnis 1 Einleitung 4 2 Scheduling Verfahren Einführung Block Scheduling Cyclic Scheduling Self Scheduling Factoring Scheduling Affinity Scheduling WITH-loops in SAC WITH-loops Verteilter Code für WITH-loops taskselectors und taskschedulers tasks Einteilung der tasks Der Taskselector Even Der Taskselector Factoring Verwaltung der tasks Static Taskscheduler Self Taskscheduler Affinity Taskscheduler Implementation Einführung Einteilung der tasks Der Taskselector Even Der Taskselector Factoring Verwaltung der tasks Grenzen initialisieren Static Taskscheduler Self Taskscheduler Affinity Taskscheduler Bestimmung der nächsten task beim Affinity Taskscheduler

3 6 Laufzeitverhalten Einführung Relaxation Relaxation ohne zusätzliche Rechenlast Relaxation mit zusätzlicher Rechenlast Das Beispiel unbalanced unbalanced ohne zusätzliche Rechenlast unbalanced mit zusätzlicher Rechenlast unbalanced auf einer 24 Prozessormaschine Zusammenfassung 46 3

4 1 Einleitung In dieser Arbeit geht es um die verteilte Ausführung von SAC-Programmen. Single Assignment C ist eine strikte, rein funktionale Programmiersprache erster Ordnung, die unter besonderer Berücksichtigung der Bedürfnisse numerischer Anwendungen entworfen wurde. Hierzu bietet SAC die Möglichkeit Array-Operationen auf einem hohen Abstraktionsniveau zu definieren, einschließlich dimensions-invarianter Programmspezifikationen. Da SAC eine funktionale Sprache ist, sind SAC-Programme seiteneffektfrei und erfüllen die Church-Rosser-Eigenschaft, das heißt, die Bedeutung des Programms ist unabhängig von der Berechnungsreihenfolge. Eine detaillierte Einführung in SAC gibt es in [1]. Für diese Arbeit sind besonders die in SAC vorhandenen WITH-loops interessant. Eine WITH-loop ermöglicht es Operationen auf Bereiche eines Arrays anzuwenden. Dabei berechnet sie aus gegebenen Arrays als Rückgabewert entweder ein neues Array oder einen einzelnen Wert, wobei die Elemente des Arrays unabhängig von einander berechnet werden. Da in einer WITHloop keine Berechnungsreihenfolge der Elemente garantiert ist, ist es einfach WITH-loops verteilt auszuführen. Bei dieser Verteilung werden in der Regel einzelne Bereiche der Berechnung auf Arrays auf die vorhandenen Prozessoren aufgeteilt. Der Code einer WITH-loop gibt dabei an, welche Berechnungen auf diesem Bereich durchgeführt werden, so daß für die Verteilung nur noch die Bereichsgrenzen angegeben werden müssen. Die Prozessoren berechnen dann bestimmte Bereiche eines Arrays mit Hilfe des Codes der WITH-loop. Hierfür verwendet SAC POSIX threads und shared memory Architekturen. Näheres zur verteilten Berechnung von WITH-loops ist in [2] und [3] zu finden. Für die Zuweisung der Bereiche einer WITH-loop an die einzelnen threads ist ein scheduling verantwortlich. Ein scheduling nimmt dabei die Einteilung der zu berechnenden WITH-loop in Teilbereiche vor und verteilt diese dann im Laufe der Berechnung an die einzelnen threads. Der einfachste Ansatz hierfür ist es genauso viele Teilbereiche gleicher Größe des Arrays wie threads zu erzeugen. Dieses ist ein guter Ansatz, solange alle Teilbereiche den gleichen Berechungsaufwand haben. Sobald dieser Berechnungsaufwand aber unterschiedlich ist, führt diese Aufteilung zu einer ineffizienten Berechnung der WITH-loop. Ein weiterer Grund, wieso es zu einer ineffizienten Berechnung der WITH-loop kommen kann, ist, daß nicht gewährleitet sein muß, daß alle threads die gleiche Rechenleistung zur Verfügung haben. Die Unterschiede in der zur Verfügung stehend Rechenleistung kommen daher, daß nicht garantiert ist, daß ein thread einen Prozessor alleine 4

5 nutzen kann. Insbesondere kann das Betriebssystem Rechenzeit des durch den thread genutzten Prozessors anderen Prozessen zuweisen. Dieses kann dazu führen, daß threads zur Berechnung von Bereichen mit gleichem Berechnungsaufwand unterschiedlich lange brauchen. Es gibt insgesamt zwei Ansätze zur Verteilung von Teilberechnungen an threads: statische Verteilung dynamische Verteilung Bei der statischen Verteilung ist jedem thread schon vor dem Start der Berechnung bekannt, welche Teilberechnungen durch ihn berechnet werden sollen. Bei diesem Verfahren hat das scheduling aber zur Laufzeit keine Möglichkeiten ein Ungleichgewicht in der Berechnungsdauer der einzelnen Teilberechnungen festzustellen oder gar auszugleichen. Dies ermöglicht ein zweiter Ansatz bei dem die Teilberechnungen erst zur Laufzeit dynamisch an die einzelnen threads verteilt werden, um eine möglichst gleichmäßige Auslastung aller threads zu erreichen. Eine Möglichkeit eine WITH-loop an threads zu verteilen, wäre jedes Element einzeln an die vorhandenen threads zu vergeben. Dieses kann aber insbesondere bei dynamischen Verfahren zu Mehraufwand durch Kommunikation führen, da das scheduling zur Laufzeit synchronisieren muß, welche Elemente durch welchen thread berechnet werden sollen. Deswegen ist es sinnvoller größere Bereiche von Elementen zu einer sogenannten task zusammenzufassen und dann diese tasks an die threads zu verteilen. Hierfür läßt sich ein scheduling in zwei Teile unterteilen: den taskselector, der eine WITH-loop in tasks einteilt, und einen taskscheduler, der diese tasks an die einzelnen threads verteilt. Durch diese Aufteilung lassen sich verschiedene Einteilungsverfahren mit verschiedenen Verteilungsalgorithmen kombinieren. Dieses erleichtert die Implementation von Varianten von schedulings, da auf bestehende taskselectors und taskschedulers zurückgegriffen werden kann. So kann zum Beispiel für ein bestimmtes Problem ein taskselector speziell optimiert und je nach Gegebenheit mit statischen oder dynamischen Verteilungsverfahren kombiniert werden. In dieser Arbeit wird erklärt wie eine Aufteilung von schedulings in taskselectors und taskschedulers erreicht werden kann. Die vorliegende Arbeit gliedert sich wie folgt: Im zweitem Kapitel werden verschiedene schedulings im Detail vorgestellt. Danach wird im dritten Kapitel eine kurze Einführung in WITH-loops und verteilte Codeerzeugung für WITH-loops in SAC gegeben. Im vierten wird dann die Aufteilung eines schedulings in einen taskselector und einen taskscheduler erläutert. Die Implementationen der taskselectors 5

6 und taskschedulers werden im fünften Kapitel vorgestellt. Im sechsten Kapitel werden dann Laufzeitergebnisse der einzelnen Algorithmen vor- und einander gegenübergestellt und schließlich werden im siebten Kapitel kurz noch mal die Ergebnisse dieser Arbeit zusammengefasst. 6

7 2 Scheduling Verfahren 2.1 Einführung Die hier vorgestellten scheduling Algorithmen verteilen einen Iterationsraum an mehrere threads. Hierbei werden statische und dynamische Verfahren verwendet um Iterationen auf die vorhandenen threads zu verteilen. Statische Verfahren weisen vor der Berechnung den threads Iterationen zu und vermeiden so zur Laufzeit Overhead bei der Berechnung, wie zum Beispiel Kommunikation zwischen einzelnen threads. Dynamische Verfahren hingegen führen erst zur Laufzeit eine Verteilung der Iterationen an die threads durch. Hierdurch ist es möglich gegebenenfalls auftretende Unterschiede in der Berechnungsdauer von den threads zugewiesenen Iterationen auszugleichen. Hierfür muß das scheduling aber zur Laufzeit abgleichen, welche Iterationen durch welchen thread berechnet werden. Dieses führt zu einem Kommunikationsmehraufwand zwischen den threads. In diesem Kapitel werden die einzelnen schedulings außer dem Factoring Scheduling anhand eines einfachen abstrakten Beispiels erläutert. Dieses Beispiel besteht aus bis zu neun Teilberechnungen für die jeweils eine bestimmte Berechnungsdauer vorgegeben ist. Hierbei unterteilen alle schedulings die Berechnung in Teilbereiche mit gleich vielen Iterationen. Die Berechnungsdauer der einzelnen Teilberechnungen wird nur zur Verdeutlichung des Ablaufes der einzelnen schedulings verwendet und läßt keine Schlüsse auf die Effizienz der hier vorgestellten Algorithmen zu. 2.2 Block Scheduling Das Block Scheduling [4] führt eine statische Verteilung der Iterationen durch. Dabei teilt es den Iterationsraum in Anzahl der threads Blöcke mit ungefähr gleich vielen aufeinander folgenden Iterationen ein. Das Problem wird dann auf die threads verteilt, indem jedem thread genau ein Block zugewiesen wird. Abbildung 1 zeigt eine verteilte Berechnung für ein Problem mit 3 Blöcken und 3 threads. Die Zahlen in den Kästen der Blöcke geben den benötigten Zeitaufwand eines threads für diesen Block an. Das rechte Diagramm zeigt in welcher Reihenfolge thread 1 (t1), thread 2 (t2) und thread 3 (t3) die Blöcke auf ihren jeweiligen Prozessoren berechnen. Die Nummern neben den Pfeilen geben dabei die Nummern der einzelnen Blöcke an und die Länge entspricht dem Berechnungsaufwand. Insgesamt benötigt das Block Scheduling eine Zeitaufwand von 12 Zeiteinheiten zur Berechnung des abstrakten Problems. Dieser Zeitaufwand ergibt 7

8 Abbildung 1: Block Scheduling für ein abstraktes Beispiel sich aus der Berechnungsdauer des 1. thread, der am längsten bis zum Ende seiner Berechnung braucht. Wie hier gut zu sehen ist, hat der thread 2 bei dieser Verteilung eine lange Wartezeit, da der Berechnungsaufwand der Blöcke 1 und 2 sich um den Faktor zwei unterscheidet. 2.3 Cyclic Scheduling Eine Möglichkeit, Berechnungsaufwand, der irgendwie proportional zum Wert der Indexposition der Berechnung ist, auszugleichen, ist das Problem in mehr Teilbereiche von Iterationen als threads einzuteilen und diese dann statisch an die threads zu verteilen. Dieses Verfahren verwendet das Cyclic Scheduling [4], wobei die Anzahl der Iterationen in den einzelnen Teilbereichen gleich eins ist. Ein leicht abgewandeltes Verfahren, das Block-Cyclic Scheduling, verwendet Teilbereiche gleicher Größe mit mehr als einer Iteration. Jeder thread arbeitet beim Cyclic Scheduling periodisch die Teilbereiche der Iterationen ab. Seien die Teilbereiche von 1 bis M AX BEREICHE nummeriert und die threads von 1 bis MAX T HREADS. Dann berechnet der t-te thread die Iterationsbereiche mit den Nummern MAX BEREICHE t t + i MAX T HREADS, für 0 i. MAX T HREADS 8

9 Durch die gleichmäßige, periodische Verteilung der Teilberechnungen über das Problem läßt sich oft ein unterschiedlicher Berechnungsaufwand für die einzelnen threads vermeiden. Dies geschieht dadurch, daß bei einer genügend großen Anzahl von Teilbereichen jeder thread sowohl Teile des Problems mit hohem als auch niedrigem Berechnungsaufwand zugewiesen bekommt. Ein typisches Problem hierfür sind Dreiecksmatrizen. Angenommen eine linke untere n n-dreiecksmatrix wird durch 3 threads berechnet. Dann würde beim Block Scheduling der 1.thread 11%. der 2.thread 33% und der letzte thread 56% der Matrix berechnen. Wenn hingegen das Cyclic Scheduling so eine Matrix in 9 Teilbereiche aus gleich vielen Zeilen unterteilt und diese an 3 threads verteilt, berechnet der 1.thread 26%, der 2.thread 33% und der 3.thread 41% der Matrix. Also ist bei diesem scheduling der Berechnungsaufwand besser verteilt als beim Block Scheduling. Abbildung 2 zeigt das abstrakte Beispiel, das jetzt in 9 Teilbereiche einge- Abbildung 2: Cyclic Scheduling für ein abstraktes Beispiel teilt ist. Die vom Block Scheduling eingeteilten Iterationsbereiche wurden für das abstrakte Problem jeweils noch mal in drei Teilbereiche eingeteilt, um den Ablauf des Cyclic Schedulings besser darzustellen. Insgesamt benötigt das Cyclic Scheduling einen Zeitaufwand von 10 Zeiteinheiten zur Berechnung dieses abstrakten Problems. Dieser Zeitaufwand ergibt sich aus der Berechnungsdauer des 3.threads, der als letzter seine Berechnung beendet und die Teilbereiche 3, 6 und 9 berechnet. Die Summe des 9

10 Zeitaufwandes dieser Bereiche beträgt gerade 10 Zeiteinheiten. 2.4 Self Scheduling Dynamische Verfahren versuchen Ungleichgewichte im Berechnungsaufwand dadurch auszugleichen, daß die Iterationen den threads erst zur Laufzeit zu gewiesen werden. Dies geschieht, da in der Regel kein Vorwissen über den Berechnungsaufwand eines Problems bekannt ist. Allerdings muß das scheduling hierbei zur Laufzeit abgleichen, welcher thread welche Iteration berechnet, was zu einem zusätzlichen Komunnikationsaufwand führt. Das einfachste dieser Verfahren ist das Self Scheduling [5]. Hierbei werden alle noch zu berechnenden Iterationen in einer zentralen Queue verwaltet. Aus dieser Queue holen sich die threads im exklusiven Zugriff dann immer ihre nächsten zu berechnenden Iterationen. Auch bei diesem Verfahren werden Teilbereiche der Iterationen mit möglichst gleicher Anzahl verwendet und den threads zu gewiesen. Das Ziel dieses scheduling ist es einen Ausgleich des Berechnungsaufwandes dadurch zu erreichen, daß immer der thread mit dem bis dahin geringsten Berechnungsaufwand sich die nächsten Iterationen abholt. Um eine effiziente Berechnung des Problems zu erreichen, sind mehr Teilbereiche der Iterationen als threads nötig, da nur hierdurch eine gleichmäßige Verteilung des Berechnungsaufwandes möglich ist. Abbildung 3 zeigt wie Self Scheduling für das abstrakte Beispiel ablaufen kann. Wie hier zu sehen ist, holen sich zuerst alle drei threads einen Teilbereich der Iterationen aus der zentralen Queue. Nach Berechnung ihrer Iterationen holt sich dann jeder thread einen neuen Teilbereich. Dieses führt in diesem Beispiel dazu, daß thread 2 insgesamt 4 Bereiche berechnet und Self Scheduling für dieses Problem einen Zeitaufwand von 12 Zeiteinheiten benötigt, da thread 2 die Teilbereiche 2, 4, 7 und 9 berechnet und damit den größten Zeitaufwand der drei threads hat. Dieses Verfahren hat den Nachteil, daß alle threads auf eine einzige zentrale Queue zugreifen. Dies wird oft noch dadurch verstärkt, daß die einzelnen Teilbereiche gleich groß sind und es somit leicht bei nahezu gleichen Berechnungsaufwand dieser Bereiche dazu kommen kann, daß sich zwei threads beim Zugriff auf die Queue gegenseitig behindern. 10

11 Abbildung 3: Self Scheduling für ein abstraktes Beispiel 2.5 Factoring Scheduling Um den Kommunikationsaufwand des Self Scheduling zu senken, verwendet das scheduling Factoring [6] Teilbereiche unterschiedlicher Grösse. Hierbei nimmt die Grösse der Bereiche mit Anzahl der berechneten Iterationen ab. Dadurch wird erreicht, daß die threads erst einen größeren Teil der Berechnung absolvieren, bevor sie sich wieder neue Iterationen abholen. Hinzu kommt, daß die kleineren Iterationsbereiche am Ende der Berechnung es ermöglichen ein Ungleichgewicht beim Berechnungsaufwand zwischen den einzelnen threads besser auszugleichen, da ein thread mit weniger Berechnungsaufwand sich in kleinen Schritten einem thread mit höherem Berechnungsaufwand anpassen kann. Das scheduling Factoring verwendet dazu genau, wie das Self Scheduling, eine zentrale Queue zur Verwaltung der einzelnen Teilbereiche. Es haben immer Anzahl der threads Teilbereiche die gleiche Größe und die Größe der nächsten Bereiche ist dann: REST IT ERAT IONS + 1, 2 MAX T HREADS wobei REST IT ERAT IONS die noch zu berechnende Größe des Restproblems angibt. Ein Beispiel für die Größen von Iterationsbereichen, bei dem 800 Iterationen 11

12 auf 4 Prozessoren verteilt werden, ist in Abbildung 4 zusehen. 800 Iterationen und 4 Prozessoren Abbildung 4: Bereichsgrößen bei Factoring 2.6 Affinity Scheduling Alle bisher beschriebenen Verfahren gehen davon aus, daß die Berechnung einer bestimmen Iteration für alle threads den gleichen Zeitaufwand auf den verwendeten Prozessoren hat und daß deswegen keine Bevorzugung (Affinität) besteht bestimmte Iterationen einen bestimmten thread zuzuweisen. Allerdings gilt diese Annahme für moderne shared memory Multiprozessorsysteme mit Prozessor eigenen Cache und eventuell nicht gleichmässigen Speicherzugriffszeiten nicht. Ein thread auf einen Prozessor, der einen Großteil der benötigten Daten schon in seinem Cache hat, wird eine Iteration in deutlich geringerer Zeit berechnen, als ein Prozessor, der diese Daten erst noch in seinen Cache laden muß. Deswegen ist die Lokalität von Daten ein entscheidender Faktor zur effizienten Berechnung von Iterationen auf shared memory Architekturen [7, 8, 9]. Ein Ansatz, der dies berücksichtigt, ist das Affinity Scheduling [10]. Genauso wie Self Scheduling verwaltet dieses die zu berechnenden Iterationen dynamisch. Im Gegensatz zu diesem hat hierbei jeder thread eine eigene Queue mit Iterationen, die durch ihn berechnet werden sollen. Dieses vermeidet das sich threads gegenseitig beim exklusiven Zugriff auf eine zentrale Queue behindern, wie dies beim Self Scheduling und beim Factoring Scheduling der Fall sein kann. Anfangs holt sich jeder thread aus seiner eigenen Queue den nächsten Teilbereich an Iterationen ab. Wenn dann die eigene Queue eines threads leer ist, holt sich dieser einen Bereich aus der Queue des threads, der bisher am wenigstens Iterationen seiner Queue abgearbeitet hat. Hierbei ist es sinnvoll, wenn beim Entlasten eines threads die Iterationsbereiche vom Ende der Queue entfernt werden, weil hierdurch eine Lokalität der Daten erreicht wird. Da somit ein thread erst dann Daten eines anderen threads benötigt, wenn er seine eigene Berechnung bereits abgeschlossen hat. Da in der Regel kein Vorwissen über Datenabhängigkeiten in der Berechnung und damit eventuelle Affinitäten der einzelnen threads bei der Berechnung 12

13 vorhanden ist, werden beim Affinity Scheduling die Queues der einzelnen threads mit gleich großen Bereichen an Iterationen vorbelegt. Auch das Affinity Scheduling kann nur dann eine gleichmäßige Verteilung des Berechnungsaufwandes erreichen, wenn es insgesamt mehr Teilbereiche als threads gibt. Abbildung 5 zeigt anhand des abstrakten Problems wie dieses Verfahren Abbildung 5: Affinity Scheduling für ein abstraktes Beispiel arbeitet. Zum erreichen einer Datenaffinität wurde bei diesem Problem eine Blockverteilung der Iterationen auf die Queues vorgenommen. Die Queue von thread 1 besteht bei diesem Beispiel aus den Iterationsbereichen 1, 2 und 3 die von thread 2 aus 4, 5 und 6 und die von thread 3 aus 7, 8 und 9. thread 2 hat als erster seine Queue abgearbeitet und entlastet dann thread 1, der als einziger noch einen unvergebenen Bereich in seiner Queue hat, indem er Teilbereich 3 berechnet. Hierdurch benötigt das Affinity Scheduling einen Zeitaufwand von 10 Zeiteinheiten, da thread 2 als letzter seine Berechnung beendet. 13

14 3 WITH-loops in SAC 3.1 WITH-loops Komplexe Operationen auf Arrays werden in SAC mit Hilfe von WITH-loops realisiert. WITH-loops definieren entweder die shape, d.h. die Größe des Arrays auf den einzelnen Dimensionen, eines neu erzeugten Arrays zusammen mit der Initialisierung der einzelnen Elemente oder eine fold-operation zusammen mit einer Berechnung der Operanden für das fold. Hierbei besteht eine WITH-loop aus zwei Teilen: einem Generator einer Operation res = with(.<iv<.) genarray([4,4],1); res = Abbildung 6: Eine genarray-with-loop, zusammen mit der generierten Matrix Der Generator definiert eine Menge von Indexvektoren zusammen mit einer Indexvariablen (siehe Abbildung 6: Definition von iv), die die Elemente dieser Menge darstellt. Die obere und untere Grenze des Bereiches der Indexvektoren werden definiert durch zwei Ausdrücke, die zu Vektoren mit gleicher Länge ausgewertet werden müssen. Des weiteren gibt es drei verschiedene WITH-loop-Operationen: genarray modarray fold Mit Hilfe von genarray läßt sich ein neues Array angeben, dessen indizierte Elemente mit einem angegeben Ausdruck und die restlichen Elemente mit 0 initialisiert werden (siehe Abbildung 6). 14

15 res = with(.<iv<.) modarray(res,res[iv]+1); res = Abbildung 7: Eine modarray-with-loop, zusammen mit der aus obiger Matrix res berechneten Matrix Modarray erzeugt aus einem existierenden Array ein neues Array, wobei indizierte Elemente durch einen angegeben Ausdruck verändert und die restlichen Elemente kopiert werden (siehe Abbildung 7). Schließlich führt fold die Reduktion eines Arrays durch Anwendung einer Operation startend mit einem neutralen Element auf alle indizierten Elemente des Arrays durch (siehe Abbildung 8). Für aufeinander folgende WITH-loops bietet SAC die Optimierung des result = with(.<iv<.) fold(+,0,res[iv]); result = 8 Abbildung 8: Eine fold-with-loop, zusammen mit dem berechneten Ergebnis der Matrix res WITH-loop-Folding [11, 12]. Hierbei wird versucht mehrere WITH-loops zu einer einzigen WITH-loop zusammen zufassen. Dazu werden WITH-loops der Benutzerebene in SAC interne Multigenerator WITH-loops eingebettet. Diese sind charakterisiert durch eine Sequenz von Generatoren mit paarweise verschiedenen Indexvektormengen. Weiterhin ist jeder Generator mit einer spezifischen Operation verknüpft. Durch die Optimierung des WITH-loop-Folding kann es vorkommen, daß auf unterschiedlichen Bereichen einer WITH-loop Operationen mit unterschiedlichem Berechnungsaufwand auftreten. Dieses kann bei der Verteilung der WITH-loop auf threads zu einem Ungleichgewicht im Berechnungsaufwand der einzelnen threads führen. 15

16 3.2 Verteilter Code für WITH-loops In SAC werden nur WITH-loops verteilt berechnet. Alle anderen Programmteile werden weiterhin sequentiell berechnet. Hierbei eigenen sich besonders Multigenerator WITH-loops gut für eine nicht sequentielle Programm Ausführung, da aufgrund der Church-Rosser-Eigenschaft von SAC alle Elemente der WITH-loop nebenläufig berechnet werden können. Generell gibt es bei der verteilten Ausführung von WITH-loops zwei Codescheduling_begin();... computation of with-loop elements... scheduling_end(); Abbildung 9: Code eines die WITH-loop berechenden threads teile: einen sequentiellen und einen nebenläufigen. Im sequentiellen Teil werden Datenstrukturen für die einzelnen schedulings initialisiert. Im nebenläufigen (siehe Abbildung 9) berechnet ein scheduling mit Hilfe Abbildung 10: Ablaufdiagramm für ein verteiltes SAC-Programm von threads die WITH-loop, wobei das scheduling jedem thread durch set- 16

17 zen der oberen (WL START) und unteren (WL STOP) Grenze einer WITH-loop auf den zu verteilenden Dimensionen, ihre zu berechnenden Bereiche auf der WITH-loop zu weist. Hierdurch verteilt das scheduling die einzelnen in der WITH-loop zu berechnenden Elemente an die threads. Vor jeder WITH-loop gründet der masterthread die benötigten workerthreads (siehe Abbildung 10). Nach der verteilten Ausführung werden dann die threads vor dem sequentiellen Code, der bis zur nächsten WITH-loop ausgeführt wird, terminiert. Hierdurch wird garantiert, daß die letzte WITH-loop komplett berechnet wurde. Dieses Verfahren wurde detailliert in [2] beschrieben. Durch die Terminierung der threads am Ende jeder WITH-loop ist es für ein scheduling für eine effiziente Berechnung entscheidend den Berechnungsaufwand für jede WITH-loop einzeln gleichmässig zuverteilen. 17

18 4 taskselectors und taskschedulers 4.1 tasks Wie in Kapitel 2 erläutert, werden bei der verteilten Berechnung Iterationen an threads verteilt. Zur Vermeidung von Mehraufwand durch Kommunikation zwischen den threads ist es sinnvoll mehrere Iterationen zu einer sogenannten task zusammen zufassen. Dieses gewährleistet eine bessere Granularität des Problems. Da alle schedulings eine Einteilung in tasks vornehmen müssen und dieses auch alle bis auf Factoring in der selben Art vornehmen, ist es sinnvoll die Verteilung einer WITH-loop konkret in zwei Teilprobleme aufzuteilen: Einteilung der tasks Verwaltung der tasks für die threads 4.2 Einteilung der tasks Für die Einteilung einer Berechnung in tasks gibt es viele Möglichkeiten. Hier einige Beispiele: gleich große Blöcke in einer Dimension gleich große Blöcke in mehreren Dimensionen verschieden große Blöcke in einer Dimension verschieden große Blöcke in mehreren Dimensionen Blöcke mit gleichem Berechnungsaufwand, d. h. z. Bsp. Bereiche gleicher Operationen einer Multigenerator WITH-loop Abbildung 11 zeigt grafisch die ersten vier Varianten der obigen Aufzählung. Welche Einteilung gewählt wird, hängt einerseits vom Vorwissen über den Aufwand der Berechnung, andererseits aber auch von dem gewählten scheduling ab, so sollte zum Beispiel für eine effiziente Berechnung beim Cyclic Scheduling (Kapitel 2.3) die Anzahl der tasks ein ganzzahliges Vielfaches der Anzahl der threads sein, sonst hätten einige threads eine task mehr als andere zu berechnen. 18

19 Abbildung 11: verschiedene task Einteilungen Der Taskselector Even Das einfachste Verfahren zur Einteilung von tasks, ist die WITH-loop in möglichst gleich große Blöcke in einer Dimension zu unterteilen. Dieses verwendet der Taskselector Even, der eine WITH-loop in einer beliebigen Dimension in eine vorgegebene Anzahl von tasks einteilen kann. Dabei erzeugt Even immer ein ganzzahliges Vielfaches der Anzahl der threads an tasks, da Cyclic und Affinity Scheduling hiermit in der Regel eine effizientere Berechnung der WITH-loop durchführen können. Wenn Even dies nicht tun würde, wären zum Beispiel beim Affinity Scheduling die lokalen Queues unterschiedlich lang und somit könnte es bei nahezu gleichem Berechnungsaufwand aller tasks dazu kommen, daß ein thread einen anderen mit längerer Queue entlasten müßte. Dieses würde dazu führen, daß sich zwei threads beim exklusiven Zugriff auf eine Queue gegenseitig behindern. Dieses kann aber bei nahezu gleichem Berechnungsaufwand der tasks in der Regel vermieden werden, wenn alle Queues die gleiche Länge haben. Dieser taskselector ist das übliche Verfahren zur Einteilung von tasks, wie es das Block, Cyclic, Self und Affinity Scheduling verwenden. 19

20 4.2.2 Der Taskselector Factoring Der Taskselector Factoring verwendet das Verfahren des scheduling Factoring und unterteilt das durch die WITH-loop berechnete Array in tasks mit abnehmender Größe in einer Dimension. Da Factoring erst zur Laufzeit die Größen der einzelnen tasks bestimmt, ist auch im Gegensatz zu Even nicht vor dem Start der Berechnung der WITHloop bekannt, wie viele tasks insgesamt vorhanden sind. Ein Beispiel für die Größen von tasks ist in Kapitel 2.5 zu sehen. Durch die Aufteilung in taskselectors und taskschedulers ist es möglich Factoring mit fast jedem taskscheduler zu kombinieren. Hierbei teilt Factoring dem jeweiligen taskscheduler mit, ob es noch weitere tasks zur Berechnung gibt, da nur ihm selbst bekannt ist, wann keine unberechneten tasks mehr vorhanden sind. Der einzige taskscheduler mit dem Factoring nicht zusammenarbeiten kann ist der Affinity Taskscheduler, da für diesen zur Einteilung seiner Queues vor dem Start der Berechnung die Anzahl der vorhandenen tasks bekannt sein muß. 4.3 Verwaltung der tasks Static Taskscheduler Der Static Taskscheduler führt eine statische Verwaltung der tasks durch. Im Zusammenspiel mit dem Taskselector Even realisiert der Static Taskscheduler das Block und Cyclic Scheduling. Dies ist nur davon abhängig, wie viele tasks Even erzeugt, wird nur eine task pro thread erzeugt, wird das Block Scheduling realisiert. Gibt es aber mehr tasks als threads, so werden die tasks durch den Static Taskscheduler in zyklischer Ordnung an die threads verteilt und es wird dann das Cyclic Scheduling realisiert. Es ist aber auch möglich diesen taskscheduler mit dem Taskselector Factoring zusammen einzusetzen. Hierbei werden dann die tasks mit abnehmender Größe in zyklischer Ordnung an die threads verteilt, bis Factoring dem taskscheduler mitteilt, das keine tasks mehr vorhanden sind Self Taskscheduler Der Self Taskscheduler verwendet eine einzige zentrale Queue zur Verwaltung der noch nicht berechneten tasks. Aus dieser Queue holen sich die threads dann zur Laufzeit immer ihre nächste zu berechnende tasks. Generell geschieht dies immer dynamisch, d. h. ein thread holt sich die nächste task vom Anfang der Queue. Da der Zugriff auf eine zentrale Queue 20

21 für die threads exklusiv sein muß, kann dies besonders am Anfang der Berechnung einer WITH-loop zu einem großen Overhead führen. Dann kann es dazu kommen, daß alle threads zeitlich dicht aufeinanderfolgend auf die Queue zugreifen, um sich ihre erste task abzuholen, und können sich deswegen leicht Gegenseitig behindern. Um dies zu verhindern, bietet der Self Taskscheduler die Möglichkeit die erste task jedem thread statisch zuzuweisen. Wenn der Self Taskscheduler zusammen mit dem Taskselector Even verwendet wird, entspricht dies dem Self Scheduling. Denn hierbei haben alle tasks in der Queue durch die Einteilung von Even dieselbe Größe. Wird allerdings der Taskselector Factoring verwendet, haben die tasks in der Queue durch ihn eine abnehmende Größe und es wird das scheduling Factoring realisiert Affinity Taskscheduler Der Affinity Taskscheduler verwendet lokale Queues für jeden thread. In dieser Queue werden alle tasks vorgehalten die durch diesen thread berechnet werden sollen. Zuerst arbeitet bei diesem Verfahren jeder thread seine eigene Queue ab. Ist er mit dieser fertig, entlastet er den thread in dessen Queue die meisten noch nicht berechneten tasks sind, indem er vom Ende dieser Queue eine task entfernt und diese selber berechnet. Zur Verteilung der tasks auf die Queues der einzelnen threads, muß der Affinity Taskscheduler vor dem Start der Berechnung wissen, welche tasks, insbesondere wie viele vorhanden sind, damit die Queues möglichst gleich lang sind. Deswegen ist der Affinity Taskscheduler als einziger nur in Kombination mit dem Taskselector Even einsetzbar, da bei diesem bekannt ist, wie viele tasks zur Berechnung der WITH-loop vorhanden sind. 21