3 Parallele Implementierung eingebette- eingebette-ter Runge-Kutta-Verfahren
3.3 Parallelrechner mit verteiltem Adreßraum
3.3.2 Theoretische Analyse der Skalierbarkeit
Die Tatsache, daß bei der Programmierung für verteilten Adreßraum mit MPI oder ähnlichen Anwendungs-schnittstellen alle Kommunikationsoperationen explizit im Programmcode formuliert werden, ermöglicht eine relativ einfache Abschätzung der Kommunikationskosten (vgl.Rauber u. Rünger 1999b). Die Imple-mentierungen (A) und (D) führen in jeder Stufe eine Allgather-Operation sowie zur Schrittweitenkontrolle eine Allreduce-Operation aus. Der Zeitaufwand für die Kommunikation, der von der Anzahl der beteilig-ten Prozessoren und der Größe des Differentialgleichungssystems abhängig ist, läßt sich folglich abschätzen als:
Tpcomm(n) =sTallgather(p,n/p) +Tallreduce(p, 1) . (3.11) Tallgather(p,n/p)ist dabei die Zeit, die zur Ausführung einer Allgather-Operation benötigt wird, an derp Prozessoren beteiligt sind und wobei jeder Prozessor eine Nachricht, bestehend ausn/p Fließkommawer-ten, versendet.Tallreduce(p, 1)ist die Zeit, diepProzessoren für die Ausführung einer Allreduce-Operation benötigen, wobei die Nachrichten nur aus einem einzelnen Fließkommawert bestehen.
Die Ausführungszeiten der Kommunikationsoperationen, die sich für eine bestimmte Anzahl von Pro-zessorenp und eine bestimmte Nachrichtengrößemergeben, sind abhängig von der Architektur des ver-wendeten Parallelrechners. Für spezielle Topologien des zugrundeliegenden Verbindungsnetzwerks lassen sich jedoch asymptotische Schranken für die Anzahl der Übertragungsschritte angeben (vgl. Rauber u.
Rünger 2000). Die Anzahl der Übertragungsschritte für die Kommunikationsoperationen „Allgather“ und
„Allreduce“ auf verschiedenen Topologien statischer Netzwerke zeigt Tab.3.1. Die Anzahl der Übertra-gungsschritte ist dabei in Abhängigkeit von der durch das Netzwerk verbundenen Anzahl von Prozesso-ren angegeben, da diese die Anzahl der Übertragungsschritte bestimmt. In die Laufzeit geht zusätzlich die Nachrichtengrößemlinear ein, da in jedem Übertragungsschritt die Nachricht, bestehend ausm Datenele-menten, über eine Kante des Netzwerks übertragen wird. Ausgehend von dieser Annahme setzen wir
Tallgather(p,m) =mTallgather(p) (3.12)
und
Tallreduce(p,m) =mTallreduce(p) , (3.13)
wobeiTallgather(p)undTallreduce(p)die Anzahl der benötigten Übertragungsschritte bezeichnet. Die Kom-munikationszeit beträgt somit:
Tpcomm(n) =sn
pTallgather(p) +Tallreduce(p) . (3.14)
Zur Einschätzung der Skalierbarkeit betrachten wir denSpeedup,Sp(n), und dieparallele Effizienz,Ep(n), der Implementierungen. Der Speedup berechnet sich aus dem Verhältnis der Laufzeit der besten sequenti-ellen Implementierung,Tseq(n), und der Laufzeit der parallelen Implementierung bei Verwendung vonp Prozessoren,Tp(n):
Sp(n) = Tseq(n)
Tp(n) . (3.15)
Die parallele Effizienz bezeichnet das Verhältnis der Laufzeit der besten sequentiellen Implementierung zu denparallelen Kosten
Cp(n) =p·Tp(n) . (3.16)
1: // Berechne Stufenvektorv1 2: multibroadcast(η);
3: for(j:= jfirst;j≤jlast;j++)v1[j]:= fj(t+c1h,η);
4: // Berechne Stufenvektorenv2, . . . ,vs 5: for(l:=2;l≤s;l++)
6: {
7: for(j:=jfirst;j≤ jlast;j++)w[j]:=al1v1[j];
8: for(i:=2;i<l;i++)
9: for(j:=jfirst;j≤jlast;j++)w[j]+=alivi[j];
10: for(j:=jfirst;j≤ jlast;j++)w[j]:=η[j] +hw[j];
11: multibroadcast(w);
12: for(j:=jfirst;j≤ jlast;j++)vl[j]:= fj(t+clh,w);
13: }
14: // Berechne∆ηund Fehlervektore
15: for(j:= jfirst;j≤jlast;j++)
16: {
17: ∆η[j]:=b1v1[j];
18: e[j]:=b˜1v1[j];
19: }
20: for(l:=2;l≤s;l++)
21: for(j:=jfirst;j≤ jlast;j++)
22: {
23: ∆η[j]+=blvl[j];
24: e[j]+= ˜blvl[j];
25: }
26: // Berechne Skalierungsfaktoren
27: for(j:= jfirst;j≤jlast;j++)s[j]:=|η[j]|+|h·v1[j]|;
Abb. 3.2:Parallele Version der Implementierung (A) für verteilten Adreßraum.
3.3 Parallelrechner mit verteiltem Adreßraum 99
1: // Berechne Stufenvektorv1
2: multibroadcast(η);
3: for(j:=jfirst;j≤jlast;j++)
4: {
5: v˜:=h fj(t+c1h,η);
6: s[j]:=|η[j]|+|v˜|;
7: for(i:=2;i≤s;i++)wi[j]:=η[j] +ai1v;˜
8: ∆η[j]:=b1v;˜
9: e[j]:=b˜1v;˜
10: }
11: // Berechne Stufenvektorenv2, . . . ,vs 12: for(l:=2;l≤s;l++)
13: {
14: multibroadcast(wl);
15: for(j:=jfirst;j≤jlast;j++)
16: {
17: v˜:=h fj(t+clh,wl);
18: for(i:=l+1;i≤s;i++)wi[j]+=ailv;˜
19: ∆η[j]+=blv;˜
20: e[j]+= ˜blv;˜
21: }
22: }
Abb. 3.3:Parallele Version der Implementierung (D) für verteilten Adreßraum.
Für die parallele Effizienz ergibt sich somit:
Ep(n) = Tseq(n)
Cp(n) = Tseq(n)
p·Tp(n) = Sp(n)
p . (3.17)
Um den eingabeabhängigen Berechnungsaufwand zu beschreiben, wird die Größe des Differentialglei-chungssystems,n, als Parameter verwendet. Ein ideales paralleles Programm hätte eine parallele Laufzeit vonTp(n) = Tseq(n)/pund folglich einen Speedup vonpund eine parallele Effizienz von 1. Die meisten realistischen Programme erreichen diese idealen Werte jedoch nur selten, weil sie z. B. einen gewissen se-quentiellen Codeanteil enthalten oder ein bestimmter Zeitaufwand zur Durchführung von Kommunikation zwischen den Prozessoren erforderlich ist.
Basierend auf der Annahme, daß der Berechnungsaufwand wesentlich durch die Funktionsauswertun-gen der Komponentenfunktionen fjbestimmt wird und alle Funktionsauswertungen etwa die gleiche Be-rechnungszeit benötigen, benutzt man als Grundlage zur Abschätzung der Laufzeit der sequentiellen und parallelen Implementierung die zur Auswertung einer Komponentenfunktion erforderliche ZeitTf(n), die von der Systemgröße abhängig sein kann. Da in jeder dersStufen für jede dernKomponenten eine Funk-tionsauswertung durchgeführt werden muß, ergibt sich die sequentielle Laufzeit als
Tseq(n) =snTf(n) . (3.18)
Netzwerktopologie Allgather Allreduce vollständiger Graph Θ(1) Θ(1)
lineares Feld Θ(p) Θ(p)
Baum Θ(p) Θ(logp)
d-dimensionales Gitter Θ(p) Θ(√d p) d-dimensionaler Hyperwürfel Θ(p/ logp) Θ(logp)
Tab. 3.1:Asymptotische Schranken für die Anzahl der Übertragungsschritte der für die Implementierung eingebetteter Runge-Kutta-Verfahren benötigten Kommunikationsoperationen auf verschiedenen Topologien statischer Netzwerke in Abhängigkeit von der Anzahl der Prozessoren,p, die die Knoten des jeweiligen Netzwerks bilden.
Da im Fall der parallelen Implementierung jeder Prozessor in jeder Stufe nurn/pKomponenten auswertet, beträgt der parallele Berechnungsaufwand
Tcompp (n) =sn
pTf(n) = 1
pTseq(n) . (3.19)
Die parallele Laufzeit ergibt sich dementsprechend als Summe des Berechnungs- und des Kommunikati-onsaufwandes als
Tp(n) =Tpcomp(n) +Tcommp (n)
=sn
pTf(n) +sn
pTallgather(p) +Tallreduce(p) , (3.20) und wir erhalten durch Einsetzen den Speedup
Sp(n) = Tseq(n)
Tp(n) = snTf(n)
snpTf(n) +snpTallgather(p) +Tallreduce(p)
= 1 1
p+ pT1
f(n)Tallgather(p) + snT1
f(n)Tallreduce(p)
(3.21)
und die parallele Effizienz
Ep(n) = Sp(n)
p = 1
1+T1
f(n)Tallgather(p) + snTp
f(n)Tallreduce(p) . (3.22) Aus diesen Funktionen, die das Verhalten des Speedups und der Effizienz in Abhängigkeit vonp,nund sbeschreiben, lassen sich bereits einige Aussagen über die Skalierbarkeit direkt ablesen. So ist ersichtlich, daß der ideale Speedup vonpbzw. die ideale Effizienz von 1 aufgrund des erforderlichen Kommunikati-onsaufwandes nicht erreicht werden kann. Speedup und Effizienz verbessern sich jedoch, wenns,noder Tf(n) erhöht werden. Insbesondere die Vergrößerung von Tf(n) verbessert das Verhältnis zwischen Be-rechnungsaufwand und Kommunikationskosten und erhöht somit gleichzeitig Speedup und Effizienz. Die Vergrößerung vonsundnwirkt sich ebenfalls positiv auf dieses Verhältnis aus, verringert jedoch lediglich den negativen Einfluß der Allreduce-Operation; der Einfluß der Allgather-Operation bleibt unverändert.
Allerdings wird die Laufzeit der Allgather-Operation mit dem Faktor 1/pmultipliziert, so daß sich bei ei-ner Erhöhung der Anzahl der Prozessoren ihr Einfluß gegenüber dem der Allreduce-Operation verringert.
Skalierbarkeit für wachsende Prozessoranzahl
Um detailliertere Aussagen über die Skalierbarkeit treffen zu können, führen wir als ersten Ansatz eine Grenzwertbetrachtung durch, bei der wir die Anzahl der Prozessoren erhöhen, indem wirpgegen
unend-3.3 Parallelrechner mit verteiltem Adreßraum 101 lich laufen lassen und dabeisundnfesthalten. Für den Speedup erhalten wir auf diese Weise:
p→lim∞Sp(n) = lim
p→∞
1
p + 1
pTf(n)Tallgather(p) + 1
snTf(n)Tallreduce(p)
!−1
= lim
p→∞
1
pTf(n)Tallgather(p) + 1
snTf(n)Tallreduce(p)
!−1
.
(3.23)
Zur Berechnung des Grenzwertes müssen wir an dieser Stelle Annahmen über die Laufzeiten der Kom-munikationsoperationen treffen. Da die Laufzeit der Allgather-Operation,Tallgather(p), mit dem Faktor 1/p eingeht, betrachten wir dazu, wie sichTallgather(p)im Vergleich zu pverhält. Die in Tab.3.1angegebenen Beispiele für verschiedene Netzwerktopologien legen nahe, daß sich Tallgather(p) durchO(p)nach oben abschätzen läßt. Tatsächlich liefert der Algorithmus für Bäume mit Θ(p)gleichzeitig eine obere Schran-ke für beliebige zusammenhängende Netzwerktopologien, da für jeden zusammenhängenden Graph ein aufspannender Baum konstruiert werden kann. Somit erhalten wir:
p→lim∞Sp(n) = lim
p→∞ O(1) + 1
snTf(n)Tallreduce(p)
!−1
=
(Θ(1) fürTallreduce(p) =Θ(1),
0 fürTallreduce(p) =ω(1). (3.24) Analog ergibt sich für die parallele Effizienz:
p→lim∞Ep(n) = lim
p→∞ 1+ 1
Tf(n)Tallgather(p) + p
snTf(n)Tallreduce(p)
!−1
= lim
p→∞(1+O(p) +Ω(p))−1
=0 .
(3.25)
Fürsundnfest kann also bestenfalls ein konstanter Speedup erreicht werden, wenn die Allreduce-Ope-ration in konstanter Zeit ausgeführt werden kann. Dies ist allerdings nur für spezielle Netzwerktopologien, z. B. einen vollständigen Graph oder ein sternförmiges Netzwerk, möglich. Für andere Netzwerktopologi-en, deren Durchmesser mit der Anzahl der Prozessoren wächst, steigt auch die Anzahl der zur Durch-führung der Allreduce-Operation notwendigen Übertragungsschritte, was wiederum dazu führt, daß der Speedup für sehr große Prozessorzahlen gegen 0 konvergiert. Zwar ist es in der Praxis nicht möglich, die Anzahl der Prozessoren, p, über die Systemdimension, n, hinaus zu erhöhen, der theoretisch ermittelte Grenzwert fürnfest undp→∞der den Speedup beschreibenden Funktion liefert uns jedoch die praktisch relevante Aussage, daß der Speedup für festesnab einer bestimmten Anzahl von Prozessoren nicht mehr steigt oder sogar fällt. Abhängig vom konkreten Verhältnis zwischen der Geschwindigkeit der Prozessoren und der Geschwindigkeit des Verbindungsnetzwerks des verwendeten Parallelrechners kann dies bereits für p ≤ ndazu führen, daß nicht alle Prozessoren des Parallelrechners effizient genutzt werden können, um ein Problem mit vorgegebener Dimension zu lösen.
Einfluß der Problemgröße auf die Skalierbarkeit
Angesichts dieser Problematik stellt sich die Frage, ob es denn wenigstens möglich ist, alle Prozessoren eines Parallelrechners effizient auszunutzen, indem man sie zur Lösung von Problemen mit hinreichend großer Dimension verwendet. Zur Beantwortung dieser Frage führen wir eine Grenzwertbetrachtung für
n→∞undpfest durch:
Als Ergebnis erhalten wir, daß für eine beliebige, aber feste Anzahl von Prozessoren der Speedup und die Effizienz verbessert werden können, indem die Systemgröße erhöht wird. Dabei sinkt der Einfluß der All-reduce-Operation auf die Laufzeit mit wachsender Systemgröße, so daß für großenSpeedup und Effizienz allein durch das Verhältnis der Laufzeit der Allgather-Operation und der Funktionsauswertungszeit be-stimmt wird. Ist die Funktionsauswertungszeit unabhängig von der Systemgröße, kann ein bebe-stimmter, von 0 verschiedener Speedup, der jedoch kleiner alspist, nicht überschritten werden. Wächst aber die Funkti-onsauswertungszeit mit der Systemgröße, dominiert mit zunehmender Systemgröße die Berechnungszeit, und die Kommunikationszeit verliert an Bedeutung, so daß sich der Speedup an pund die Effizienz an 1 annähert.
Nutzung zusätzlicher Prozessoren bei wachsender Problemgröße
Versuchen wir nun, das Skalierbarkeitsverhalten fürp →∞in diesem Licht neu zu betrachten, indem wir der Frage nachgehen, ob wir bei einer Erhöhung der Systemgröße zusätzliche Prozessoren sinnvoll nutzen können, um den zunehmenden Berechnungsaufwand zu bewältigen. Dazu nehmen wir an, daß die Anzahl der Prozessoren im gleichen Verhältnis wie die Systemgröße gesteigert wird, d. h.n/p = c = Θ(1) ≥ 1.
Dies schließt insbesondere den interessanten Falln= pein, was bedeutet, daß zur Lösung eines Problems der Dimensionndie maximal verfügbare Parallelität bezüglich des Systems ausgenutzt wird. Unter dieser Voraussetzung erhalten wir für den Speedup:
n,p→lim∞Sp(n) = lim
Das bedeutet, daß sich durch die proportionale Steigerung vonnundpmindestens ein konstanter Speedup erhalten läßt. Die Frage ist also eindeutig mit „Ja“ zu beantworten. Unter bestimmten Voraussetzungen vergrößert sich der Speedup sogar. Dies ist der Fall, wenn die Funktionsauswertungszeit mitnwächst oder
3.3 Parallelrechner mit verteiltem Adreßraum 103 beide Kommunikationsoperationen schneller als inΘ(p)realisiert werden können, wie dies beispielsweise bei Verwendung eines Hyperwürfel-Netzwerks der Fall ist.
Eine Verfeinerung dieser Aussage liefert die Betrachtung der parallelen Effizienz. Hierfür erhalten wir unter derselben Voraussetzung:
Aus diesem Ergebnis wird ersichtlich, daß die Effizienz – und damit auch der genaue Verlauf der Speedup-Kurve – durch das Verhältnis von Funktionsauswertungszeit und Laufzeit der Kommunikationsoperatio-nen bestimmt wird. So ist eine Effizienz von 1 und somit ein Speedup von p möglich, wenn die tionsauswertungen asymptotisch aufwendiger sind als beide Kommunikationsoperationen. Haben Funk-tionsauswertungen und beide Kommunikationsoperationen asymptotisch gleiche Kosten, ergibt sich im Grenzwert eine konstante Effizienz, was einem linear steigenden Speedup entspricht. Ist jedoch mindestens eine der beiden Kommunikationsoperationen teurer als die Funktionsauswertungskosten, konvergiert die Effizienz gegen 0, da in diesem Fall der Speedup langsamer wächst als die Anzahl der Prozessoren oder er sogar stagniert. Das bedeutet, daß man zwar von zusätzlichen Prozessoren profitiert, da sie die Ausfüh-rung auch für große Probleme beschleunigen, sich das Verhältnis von Laufzeitgewinn und Hardwarekosten jedoch verschlechtert.
Ein Ansteigen der parallelen Laufzeit kann aber auch bei einem gegen ∞strebenden Speedup in der Regel nicht verhindert werden, wie die Grenzwertbetrachtung fürTp(n)fürn,p→∞mitn/p=czeigt:
n,p→lim∞Tp(n) = lim
Eine Vergrößerung der parallelen Laufzeit bei proportionaler Erhöhung vonnundperfolgt also nur dann nicht, wenn sowohlTf(n)als auchTallgather(p)undTallreduce(p)in konstanter Zeit ausgeführt werden kön-nen.
Zusammenfassung
Die Laufzeit einer parallelen Implementierung eines eingebetteten Runge-Kutta-Verfahrens für verteilten Adreßraum kann man als Summe des Zeitaufwands für die Berechnung der Funktionsauswertungen und der für die Ausführung der Kommunikationsoperationen benötigten Zeit abschätzen. Doch während sich der pro Prozessor erforderliche Berechnungsaufwand mit wachsender Prozessorzahl verkleinert, kann sich der Kommunikationsaufwand vergrößern. Zwar sinkt bei wachsender Prozessorzahl die Größe der mittels der Allgather-Operation ausgetauschten Nachrichten, so daß diese Operation nur einen geringen Einfluß auf das asymptotische Verhalten der Programmlaufzeit ausübt, für die Allreduce-Operation ändert sich die Nachrichtengröße jedoch nicht. Deshalb bestimmt die Anzahl der für die Ausführung der Allreduce-Operation notwendigen Übertragungsschritte das asymptotische Verhalten der Programmlaufzeit bei einer Vergrößerung der Prozessoranzahl. Infolgedessen bleibt der Speedup für eine gegebene Problemgröße ab einer bestimmten Prozessoranzahl konstant oder fällt sogar ab, was zu einer schlechten parallelen Effizienz führt.
Erhöht man jedoch unter Beibehaltung der Prozessoranzahl die Systemgröße, kann man den Speedup und die Effizienz verbessern, da der Berechnungsaufwand ansteigt, der Aufwand für die Ausführung der
Allreduce-Operation jedoch konstant bleibt, da die Größe der zu übertragenden Nachrichten unabhängig von der Problemgröße ist. Steigt die FunktionsauswertungszeitTf(n)mit der Problemgröße an, verringert sich mit wachsender Problemgröße auch der Einfluß der Allgather-Operation, so daß sich der Speedup dem optimalen Wertpannähert.
Betrachtet man die Skalierbarkeit unter dem Gesichtspunkt, daß man für die Lösung unterschiedlich großer Testprobleme einen konstanten Grad an Parallelität ausnutzen möchte, ergibt sich ein gutes Ska-lierbarkeitsverhalten, wenn man die Anzahl der Prozessoren im gleichen Verhältnis wie die Problemgröße erhöht. Das heißt, für große Problemgrößen und Prozessorzahlen bleibt mindestens ein konstanter Speedup erhalten, wenn man Problemgröße und Prozessoranzahl proportional erhöht. Die Entwicklung der Effizi-enz hängt dagegen davon ab, wie sich die Anzahl der zur Ausführung der Kommunikationsoperationen notwendigen Übertragungsschritte im Verhältnis zur Funktionsauswertungszeit steigert.
Eine genauere Analyse des Skalierbarkeitsverhaltens ist möglich, wenn die spezifische Architektur der Zielplattform bekannt ist. So kann bei bekannter Topologie des Verbindungsnetzwerks die Anzahl der Übertragungsschritte der Kommunikationsoperationen spezifiziert werden. Alternativ kann man Laufzeit-formeln für die Kommunikationsoperationen durch Ausgleichsrechnung (Rauber u. Rünger 1997b) oder mittels genetischer Programmierung (Heinrich-Litan u. a. 1998) anhand empirischer Daten ermitteln (siehe auchRauber u. Rünger 2000). Liegen Laufzeitformeln vor, die das Verhalten der Kommunikationsopera-tionen hinreichend genau beschreiben, kann eine detaillierte Analyse des Skalierbarkeitsverhaltens mittels Methoden der Kurvendiskussion, einschließlich der Bestimmung von Extremwerten, durchgeführt werden.