LR-Zerlegung dünnbesetzter Matrizen für Parallelrechner mit ... - ZIB

Diplomarbeit
LR-Zerlegung dünnbesetzter
Matrizen für Parallelrechner mit
verteiltem Speicher
Michael Ganß
rms@cs.tu-berlin.de
Matrikelnummer 131071
Februar 1997
Betreuer:
Prof. Dr. Stefan Jähnichen
Prof. Dr. Peter Pepper
Technische Universität Berlin
Fachbereich Informatik
Institut für Kommunikations- und Softwaretechnik
Fachgebiet Softwaretechnik
Sekretariat FR 5-6
Franklinstraße 28/29
D-10587 Berlin

Inhaltsverzeichnis
1 Einleitung 1
2 Lösung linearer Gleichungssysteme 5
2.1 LR-Zerlegung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Generischer LR-Zerlegungs-Algorithmus . . . . . . . . . . . . . . . 12
3 Parallele LR-Zerlegung 17
3.1 Der massiv-parallele Rechner Cray T3D . . . . . . . . . . . . . . . . 17
3.2 Paralleles Programmiermodell . . . . . . . . . . . . . . . . . . . . . 18
3.3 Eingesetzte Funktionen und Klassen . . . . . . . . . . . . . . . . . . 19
3.4 Der parallele Algorithmus . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.1 Die PCAM-Methode . . . . . . . . . . . . . . . . . . . . . . 23
3.4.2 Partitionierung . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.3 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4.4 Agglomeration und Abbildung . . . . . . . . . . . . . . . . . 29
3.5 Die Klasse DSLUFactor . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5.1 Datenverteilung . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5.2 Elimination von Singletons . . . . . . . . . . . . . . . . . . . 32
3.5.3 Faktorisierung des Nukleus . . . . . . . . . . . . . . . . . . . 34
3.6 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.6.1 Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.6.2 Load-Balancing . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.6.3 Aufwandsparameter paralleler Algorithmen . . . . . . . . . . 65
3.6.4 Faktorisierungszeiten . . . . . . . . . . . . . . . . . . . . . . 66
4 Parallele Lösung von Dreieckssystemen 73
4.1 Sequentieller Algorithmus . . . . . . . . . . . . . . . . . . . . . . . 73
4.2 Paralleler Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.2.1 Partitionierung . . . . . . . . . . . . . . . . . . . . . . . . . 76
I

Inhaltsverzeichnis
4.2.2 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . 77
4.2.3 Agglomeration und Abbildung . . . . . . . . . . . . . . . . . 77
4.3 Implementierung des parallelen Algorithmus . . . . . . . . . . . . . 80
4.4 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5 Zusammenfassung 91
II

Danksagung
Das in dieser Arbeit beschriebene Programm entstand am Konrad-Zuse-Zentrum Berlin.
Mein besonderer Dank gilt dort Roland Wunderling für die geduldige und präzise
Beantwortung all meiner Fragen, die stets kompetente Beratung in technischen
Angelegenheiten sowie die kritische und konstruktive Begutachtung meines Arbeitsfortschritts.
Hans-Christian Hege danke ich für die Freiheiten, die er mir am ZIB
gewährte und die Bemühungen, die er meinetwegen unternahm. Danken möchte ich
auch Gabi Keller und Manuel Chakravarty vom Fachgebiet Softwaretechnik für die
Beantwortung meiner Fragen sowie die hilfreichen Hinweise und Anregungen, die sie
mir gaben.

1 Einleitung
In vielen wissenschaftlichen Bereichen stößt man auf die Notwendigkeit, lineare Gleichungssysteme
lösen zu müssen, so u. a. in Disziplinen wie der Astrophysik, der Erdöltechnik
oder bei der Modellierung von wirtschaftlichen Prozessen [10]. Generell
ist man bei Verfahren in vielen Feldern der angewandten Mathematik auf die Lösung
von linearen Gleichungssystemen angewiesen, so z. B. bei der Lösung von Differentialgleichungen
[12] oder bei der linearen Programmierung [5]. Nicht viele Probleme,
die in der Informatik untersucht werden, haben ein größeres Anwendungsfeld in der
realen Welt.
Parallele Programmierung Obwohl Computer immer schneller werden, und man
vermuten könnte, daß sie früher oder später schnell genug werden, um den Bedarf an
erhöhter Rechenleistung zu stillen, gibt es stets neue Anwendungen, die nach einer
weiteren technologischen Entwicklung verlangen (ganz abgesehen von wirtschaftlichen
Interessen, die hier aber vernachlässigt werden). So gibt es z. B. im Simulationsbereich
Anwendungen, die sich durch Hinzunahme neuer Parameter oder Verfeinerung
der Auflösung beliebig komplex machen lassen [11, Kapitel 1].
In den letzten 40 Jahren hat sich die Geschwindigkeit von Prozessoren etwa alle 2
Jahre verdoppelt (“Moore’s law” [17]). Es zeichnet sich aber ab, daß dies nicht mehr
lange möglich sein wird, da irgendwann elementare physikalische Grenzen erreicht
sein werden. Auch “instruction level parallelism” (längere Pipelines, mehr Funktionseinheiten)
kann nicht beliebig erhöht werden. Man kann also nicht auf schnellere
Prozessoren als Garanten für verbesserte Rechenleistung vertrauen. Es bietet sich
daher an, mehrere Rechner parallel an der Lösung eines Problems in kürzerer Zeit
arbeiten zu lassen. Konsequenterweise wird Nebenläufigkeit ein fundamentales Erfordernis
für Algorithmen und Programme sein.
Aufgabenstellung In dieser Arbeit wird ein paralleles Programm zur Lösung eines
linearen Gleichungssystems Ax = b entwickelt.
Matrizen aus konkreten Anwendungsbereichen wie oben erwähnt sind fast aus-
1

1 Einleitung
schließlich dünnbesetzt, d. h. cn der n 2 Elemente der Matrix A sind ungleich Null,
wobei c

Aufbau In Kapitel 2 wird das Verfahren der LR-Zerlegung erläutert und ein sequentieller
Algorithmus zur Durchführung desselben vorgestellt. Im darauffolgenden
Kapitel wird, nach einer zuvorigen Darstellung der hard- und softwaretechnischen Bedingungen,
ein paralleler LR-Zerlegungs-Algorithmus entwickelt und dessen Implementierung
beschrieben sowie die mit diesem Algorithmus gesammelten Ergebnisse
diskutiert. Kapitel 4 behandelt den Entwurf und die Implementierung eines parallelen
Algorithmus zur Lösung von Dreieckssystemen, wie sie bei der LR-Zerlegung von
Koeffizientenmatrizen allgemeiner Gleichungssysteme entstehen. Dort werden auch
die mit der Implementierung erzielten Ergebnisse diskutiert. In Kapitel 5 werden die
in dieser Arbeit gewonnenen Erkenntnisse zusammengefaßt.
3

1 Einleitung
4

2 Lösung linearer Gleichungssysteme
In diesem Kapitel soll zunächst im ersten Abschnitt das Verfahren der LR-Zerlegung
zur Lösung eines linearen Gleichungssystems erläutert werden. Ausgehend von vereinfachten
Gleichungssystemen soll das Verfahren auf allgemeine Gleichungssysteme
ausgedehnt werden. Im zweiten Abschnitt des Kapitels soll dann ein sequentieller Algorithmus
zur Umsetzung des Verfahrens vorgestellt werden.
2.1 LR-Zerlegung
Ein lineares Gleichungssystem mit ebensovielen Gleichungen wie Unbekannten hat
die Form
++a ++a
a 11 x 1 + a 12 x 2
a 21 x 1 + a 22 x 2
.
a n1 x 1 + a n2 x 2 ++a
1n
2n
nn
oder kurz in Matrixschreibweise
Ax = b.
x n = b 1
x n
.
= b 2
.
(2.1)
x n = b n
A ist eine reelle n×n Matrix und b,x sind reelle Vektoren der Dimension n. Die Matrix
A und der Vektor b sind gegeben und x ist der unbekannte Lösungsvektor.
Lösung von Dreieckssystemen
++r ++r
r 11 x 1 + r 12 x 2
r 22 x 2
1n
2n
Ein Gleichungssystem der Form
x n = y 1
x n = y 2
. .. .
.
(2.2)
r nn x n = y n
5

2 Lösung linearer Gleichungssysteme
kurz
Rx = y
heißt Dreieckssystem und läßt sich sehr einfach direkt lösen. R ist eine obere Dreiecksmatrix
(“upper triangular matrix”), d. h. r i j = 0 für alle i > j. Unter der Voraussetzung,
daß r j j ≠ 0, erhält man die Lösung durch sukzessives Einsetzen der Teillösungen von
unten her. Aus der letzten Gleichung erhält man die Lösung für x n , diese setzt man in
die vorletzte ein und erhält somit x n−1 usw.
x n = y n
r nn
x n−1 = (y n−1−r n−1n x n )
r n−1n−1
.
x 1 = (y 1−r 12 x 2 −:::−r
1n x n )
r 11
(2.3)
Das so durchgeführte Lösen heißt Rückwärtssubstitution (“backward solve”). In gleicher
Weise läßt sich auch ein Gleichungssystem der Form
Ly = b (2.4)
lösen, wobei L eine untere Dreiecksmatrix (“lower triangular matrix”) ist, d. h. l i j = 0
für alle j > i. Dieses Auflösen nennt man Vorwärtssubstitution (“forward solve”).
Faktorisierung von A Um allgemeine Gleichungssysteme der Form (2.1) zu lösen,
kann man sich der Methode (2.3) bedienen, wenn es gelingt, die Koeffizientenmatrix
A äquivalent in das Produkt einer unteren Dreiecksmatrix L und einer oberen Dreiecksmatrix
R zu transformieren, da
b = Ax = (LR)x = L(Rx) ⇒ Ly = b, Rx = y.
Eine solche Transformation leistet die LR-Zerlegung 1 . Ein allgemeines Gleichungssystem
der Form (2.1), dessen Koeffizientenmatrix in die Faktoren L und R transformiert
werden kann, läßt sich mittels LR-Zerlegung unter Einhaltung folgender Schritte lösen:
1 Im Englischen LU factorization wg. “lower-upper” vs. “links-rechts”.
6

2.1 LR-Zerlegung
a) A = LR Zerlegung in obere und untere Dreiecksmatrix
b) Ly = b Vorwärtssubstitution
c) Rx = y Rückwärtssubstitution
Um die Faktoren L und R zu bestimmen, erzeugt man bei der LR-Zerlegung ausgehend
von A = A (1) in mehreren Transformationsschritten Matrizen A (s) , die sich immer
mehr der rechten oberen Dreiecksmatrix R annähern. Die Transformationen werden
durch Multiplikation der A (s) von links mit Transformationsmatrizen L s durchgeführt.
Aus deren Produkt läßt sich einfach die untere Dreiecksmatrix L bestimmen.
Um A in eine obere Dreiecksmatrix zu transformieren, muß die erste Zeile von A
nicht verändert werden. Man setzt also
=2
A (1) := A.
Aus den restlichen Zeilen müssen die Elemente der ersten Spalte verschwinden. Dies
kann erreicht
6 375
werden, indem man man A mit
41
−l 21 1
L 1
.
.. .
−l n1 1
von links multipliziert. Dabei soll
l i1 := a i1
a 11
für i = 2,:::,n
sein. Unter der Voraussetzung a 11 ≠0 ist der erste Transformationsschritt somit durchführbar.
Man erhält die Matrix A (2) mit
A (2) := L 1 A (1) .
Das Element a 11 heißt Pivotelement (kurz Pivot), die dazugehörige Zeile Pivotzeile
(“pivot row”). Das Verfahren kann man fortsetzen, indem man die Elemente a (2)
i2
mit
i = 3,:::,n aus A (2) durch Multiplikation von A (2) mit L 2 verschwinden läßt und daraus
A (3) erhält usf. Man erhält so eine Folge
A = A (1) → A (2) →:::→A (n) = R
7

2 Lösung linearer Gleichungssysteme
von Matrizen A (s) der Gestalt
a (1) 375, 1n
a (2)
2n
. ..
A (s) =2 375
.
=
a (s)
(2.5)
sn
. .
a (s)
nn
aus denen
6
sich durch Multiplikation mit der Matrix
41
. ..
1
L s (2.6)
−l s+1s 1
.
. ..
264a (1)
11
a (1)
12
a (2)
22
ssa (s)
nsa (s)
−l ns 1
die Matrizen A (s+1) ergeben. Dabei gilt
l is := a(s) is
a (s) für i = s + 1,:::,n (2.7)
ss
unter der Voraussetzung, daß das Pivotelement a (s)
ss ≠ 0 ist. Dieser Übergang, auch
Eliminationsschritt genannt, läßt sich in Matrixschreibweise folgendermaßen ausdrücken:
A (s+1) := L s =2 A (s) .
Die Matrix L s ist eine sogenannte Frobenius-Matrix, die die Eigenschaft besitzt, daß
die Inverse L −1
s durch einen Vorzeichenwechsel in den l is mit i > s entsteht. Aus der
folgenden Definition
6 375
41
L:= L −1
n−1 L−1 n−2:::L −1 l 21 1
1 .
. .. . ..
l n1l 1
läßt sich
nn−1
R = L −1 A ⇔ LR = LL −1 A ⇔ A = LR
ableiten.
8

2.1 LR-Zerlegung
Pivotsuche Die LR-Zerlegung ist nach der oben beschriebenen Methode auch unter
der Voraussetzung, daß Ax = b eine eindeutig bestimmte Lösung besitzt, nicht immer
mittels (2.7) möglich. Für die Matrix
A =0 1
1 0,
gilt zwar det A ≠ 0, d. h. es existiert eine eindeutig bestimmte Lösung eines linearen
Gleichungssystems mit A als Koeffizientenmatrix, aber l 21 ist nicht definiert, da
a 11 = 0. Vertauscht man jedoch Zeile 1 mit Zeile 2, dann ist die LR-Zerlegung von
A ohne weiteres möglich, es ist sogar A = L = R. Dabei muß man, um die Äquivalenz
des Gleichungssystems Ax = b zu erhalten, auch die entsprechenden Zeilen von
b vertauschen.
Bei der Darstellung von reellen Zahlen als Fließkommazahlen können auch bei
“zu kleinen” Pivotelementen aufgrund von Rundungsfehlern Probleme entstehen.
Beispielsweise hat das Gleichungssystem
0.005x + y = 0.5
x + y = 1.0
(2.8)
die exakte Lösung
x = 100
99
≈ 0.5, y =
199 199 ≈ 0.5.
Führt man hingegen die LR-Zerlegung mit Fließkommaarithmetik einer Genauigkeit
auf zwei Stellen durch, so erhält man
0
1
L =1
R =0.005
(2.9)
200 1,
0 −200.
=
Daraus folgt als Lösung nach Vor- und Rückwärtssubstitution
x = 0.0, y = 0.5.
Vertauscht man jedoch wieder die beiden Zeilen, so ergibt sich
1 0
1
L R =1
(2.10)
0.005 1,
0 1,
sowie
x = 0.5, y = 0.5.
9

2 Lösung linearer Gleichungssysteme
Um die LR-Zerlegung für Koeffizientenmatrizen allgemeiner Gleichungssysteme
durchführen zu können, ist es u. U. nötig, Zeilenvertauschungen vorzunehmen. Für
jede invertierbare Matrix (d. h. mit welcher als Koeffizientenmatrix ein lineares Gleichungssystem
(2.1) eine eindeutig bestimmte Lösung besitzt) gibt es eine Folge von
Zeilenvertauschungen, so daß eine LR-Zerlegung möglich ist (für den Beweis siehe
[7, Satz 1.8]).
Um ein möglichst genaues Resultat zu erzielen, führt man die Zeilenvertauschungen
so aus, daß man im s-ten Eliminationsschritt die s-te Zeile mit derjenigen Zeile
aus den Zeilen s bis n vertauscht, die das betragsmäßig größte Element in der s-ten
Spalte besitzt. Man sucht also als Pivotelement a (s)
ss das mit dem größten Betrag in
der Pivotspalte s aus. Dieses Vorgehen nennt man Spaltenpivotsuche (“column pivoting”).
Man erhält dadurch ein i. allg. besseres Ergebnis als durch Auswahl eines
anderen Pivotelements in der Pivotspalte [7, Kapitel 2]. Man ist aber auch mit diesem
Verfahren nicht vor starken Ungenauigkeiten gefeit, wie das zu (2.8) äquivalente
System
2x + 400y = 200
x + y = 1.0
(2.11)
beweist, dessen Lösung bei Spaltenpivotsuche, d. h. wenn man nur Zeilenvertauschungen
zuläßt, dieselbe Ungenauigkeit wie von (2.8) über (2.9) aufweist.
Anstelle der Spaltenpivotsuche mit Zeilentausch kann man auch eine Zeilenpivotsuche
mit Spaltentausch durchführen. Kombiniert man beide Vorgehensweisen und
wählt das betragsmäßig größte Element a (s)
i s j s
mit i s ≥ s und j s ≥ s, so heißt dies vollständige
Pivotsuche (“total pivoting”). Mit vollständiger Pivotsuche erhielte man bei
(2.11) dasselbe (bezüglich der zweistelligen Fließkommadarstellung exakte) Ergebnis
wie bei (2.10).
Wie bereits oben angeführt, müssen etwaige Zeilenvertauschungen auch für den
Vektor b der rechten Seite vorgenommen werden. Bei Durchführung der LR-
Zerlegung für eine Koeffizientenmatrix A wird jedoch, wie in der Einleitung erwähnt,
von b abstrahiert, so daß die Vertauschungen (auch Permutationen genannt) nicht explizit
vorgenommen werden können. Aus diesem Grund merkt man sich die Permutationen
in einem n-dimensionalen Vektor π, der Permutationsvektor genannt wird.
Vertauscht man im s-ten Schritt Zeile s mit Zeile i s , so definiert man
π s := i s . (2.12)
Will man dann ein Gleichungssystem mit der rechten Seite b lösen, so definiert man
eine neue rechte Seite d mit
d i := b πi für i = 1,:::,n
10

2.1 LR-Zerlegung
und löst damit Ly = d. Führt man eine Zeilenpivotsuche durch, so kommen die Spaltenvertauschungen
einer Vertauschung der Indizes von x gleich (äquivalente Umformung
für Ax = b, da die Additionen in (2.1) kommutativ sind). Diese Vertauschungen
muß man nach Berechnung der Lösung wieder rückgängig machen. Dazu merkt man
sich die gemachten Permutationen in einem n-dimensionalen Vektor ρ. Vertauscht
man im s-ten Schritt Spalte s mit Spalte j s , so definiert man
ρ s := j s . (2.13)
Die Rückwärtssubstitution führt man für einen neuen Resultatvektor z durch und erhält
x dann aus der Definition
x ρ j
:= z j für j = 1,:::,n.
Zusammenfassend sind für allgemeine Gleichungssysteme der Form (2.1) folgende
Schritte notwendig, um die Lösung x mittels LR-Zerlegung zu bestimmen.
a) Bestimmung von L, R, π und ρ mittels LR-Zerlegung, so daß
A πi ρ j
= (LR) i j
∀i, j: i, j ∈ {1,:::,n}
b) Permutation von b nach d, so daß
d i := b πi
∀i:i ∈ {1,:::,n}
c) Bestimmung der Lösung von Ly = d mittels Vorwärtssubstitution
d) Bestimmung der Lösung von Rz = y mittels Rückwärtssubstitution
e) Permutation von z nach x, so daß
x ρ j
:= z j
∀ j: j ∈ {1,:::,n}
Die Umsetzung der LR-Zerlegung für Parallelrechner wird im nächsten Kapitel behandelt,
auf die weiteren Schritte wird in Kapitel 4 eingegangen.
11

2 Lösung linearer Gleichungssysteme
2.2 Generischer LR-Zerlegungs-Algorithmus
Der Algorithmus zur Faktorisierung einer Matrix A der Dimension n, dargestellt in
Algorithmus 2.1, besteht aus einer Folge von n − 1 Eliminationsschritten. In jedem
dieser Schritte wird ein Nichtnullelement a (s)
i s j s
der aktiven Submatrix ausgewählt, das
Pivotelement. Die aktive Submatrix im s-ten Eliminationsschritt ist die (n − s + 1)-
dimensionale Restmatrix von A (s) mit Elementen a (s)
i j aus den Zeilen und Spalten aus
denen noch kein Pivotelement ausgewählt wurde (siehe (2.5)). Man beginnt mit den
Zeilen- und Spaltenindexmengen I und J mit I = J = {1,:::,n} und entfernt aus diesen
sukzessive die Indizes der Pivotelemente, so daß die aktive Submatrix stets die Zeilen
i mit i ∈ I und die Spalten j mit j ∈ J umfaßt.
Die Vertauschungen von Zeile s mit Zeile i s und von Spalte s mit Spalte j s , die zur
Auswahl des Pivotelements notwendig sind, werden nicht explizit ausgeführt, sondern
nur in Permutationsvektoren π und ρ wie im vorigen Abschnitt beschrieben vermerkt.
Die Vertauschungen werden zum Abschluß vorgenommen, indem man die gemerkten
Vertauschungen von Zeilen und Spalten an A (n) vornimmt und so R erhält. Man
errechnet deshalb auch in jedem Schritt die Werte der Elemente ¯l i js einer temporären
Matrix ¯L, deren Zeilen und Spalten zum Abschluß des Algorithmus so wie in π und ρ
vermerkt vertauscht werden und daraus L entsteht.
Die Elemente a (s+1)
i j
, aus denen sich in jedem Eliminationsschritt A (s+1) ergibt, werden
in der Update-loop erzeugt. Bei einer Implementierung des Algorithmus rechnet
man die A (s) nicht mit, sondern führt in jedem Schritt Veränderungen (Updates) an A
aus, so daß nach Ausführung der Update-loop stets A = A (s+1) gilt. Die Begriffe sind
noch einmal in Abbildung 2.1 veranschaulicht.
In Algorithmus 2.1 ist noch nichts darüber ausgesagt, auf welche Weise das Pivotelement
bestimmt wird (Spaltenpivotsuche, Zeilenpivotsuche, . . . ). Die gewählte
Vorgehensweise in diesem Punkt hat einen großen Einfluß auf die Güte des Algorithmus
als Ganzes, die sich hier primär durch eine möglichst hohe Zeiteffizienz, aber
auch durch eine gute Genauigkeit definiert. Um beidem gerecht zu werden, müssen
beim Entwurf eines Verfahrens für die Pivotauswahl mehrere Forderungen beachtet
werden.
Vermeidung von Fill Zum einen will man möglichst die Dünnbesetztheit der Matrix
erhalten. Da für Elemente a (s)
i j s
= 0 in der Pivotspalte ¯l i js = 0 ist, beschränkt man
die L-loop auf die Nichtnullelemente der Pivotspalte und nutzt so die Dünnbesetztheit
der aktiven Submatrix zum Zwecke der Effizienzsteigerung aus. Für Elemente a (s)
i s j = 0
in der Pivotzeile sowie Elemente ¯l i js = 0 aus ¯L ist a (s+1) = a (s) , weshalb die Updateloop
auf Nichtnullelemente der Pivotzeile und -spalte beschränkt wird und man so
ebenfalls von der Dünnbesetztheit der aktiven Submatrix profitieren kann.
12

2.2 Generischer LR-Zerlegungs-Algorithmus
for s = 1 to n − 1 do
Wähle Pivot a (s)
i s j s
≠ 0 aus, mit i s ∈ I, j s ∈ J
π s := i s ;
ρ s := j s ;
I:= In{i s };
J:= Jn{j s };
for all a (s)
i j s
≠ 0 mit i ∈ I do
¯l i js := a (s)
end for
for all a (s)
a (s+1)
i j
end for
end for
l i j := ¯l πi ρ j
;
i j s=a (s)
i s j s
;
i s j ≠ 0 mit j ∈ J und ¯l i js ≠ 0 mit j ∈ J do
:= a (s)
i j
− ¯l i js ⋅ a (s)
i s j ;
{Pivot-loop}
{Zeilenpermutation festhalten}
{Spaltenpermutation festhalten}
{Pivotzeile entfernen}
{Pivotspalte entfernen}
{L-loop}
{Update-loop}
{L bilden}
r i j := ā πi ρ j
; {R bilden aus Ā = A (n) }
Algorithmus 2.1: LR-Zerlegung
Es kann jedoch sein, daß in der Update-loop neue Nichtnullelemente kreiert werden,
d. h. falls a (s)
i j
= 0 und ¯l i js ≠ 0 sowie a (s)
i s j
≠ 0, dann ist a(s+1) i j
≠ 0. a (s+1)
i j
wird dann
als Fill element, die Menge
375
aller Fill elements kurz als Fill oder Fill-in bezeichnet.
Fill gilt es zu vermeiden, da er in den darauffolgenden Eliminationsschritten zusätzliche
Kosten in der L- und Update-loop verursacht. Man ist hierbei auf Heuristiken
angewiesen, da eine optimale Lösung nicht in vertretbarem Zeitaufwand erreichbar
ist [24]. In welcher Weise die Pivotwahl den Fill beeinflußen kann, zeigt sich, wenn
man die Matrix
(2.14)
264a 11 a 12a
a 21 a 22
.
a n1
1n
. ..
a nn
betrachtet. Wählt man nämlich hier a 11 als Pivot, so ist ein Update für alle Elemente
a i j mit i > 1, j > 1 vonnöten und die aktive Submatrix ist im nächsten Eliminationsschritt
dichtbesetzt, was zu einem erheblichen Mehraufwand bei der weiteren Faktorisierung
führt. Wählt man dagegen z. B. a nn als Pivot, so ergibt sich ein Update
lediglich für a 11 und die dünnbesetzte Struktur der Matrix bleibt erhalten.
Eine Heuristik zur Auswahl eines Pivotelementes mit dem Ziel der Erhaltung der
Dünnbesetztheit der Matrix ist die Markowitz Strategie [14]. Die Wahl eines Elements
13

2 Lösung linearer Gleichungssysteme
aktive
Submatrix
Pivotspalte
ρ s := j s
Pivot
Pivotzeile
π s := i s
a (s)
i s j s
a (s)
i s j
I
¯l i js
a (s)
i j
Update
J
Abbildung 2.1: Eliminationsschritt
a i j führt dazu, daß höchstens
M i j = (r i − 1)(c j − 1) (2.15)
neue Nichtnullelemente geschaffen werden, wobei r i bzw. c j die Anzahl der Nichtnullelemente
in Zeile i bzw. Spalte j darstellen. M i j wird dabei die Markowitz-Zahl
von a i j genannt. Das Bestreben ist es also, ein solches Element als Pivot zu wählen,
das die geringstmögliche Markowitz-Zahl aufweist.
Numerische Stabilität Zum anderen will die numerische Stabilität gewahrt bleiben,
d. h. die Lösung eines linearen Gleichungssystems mit den Faktoren LR der Koeffizientenmatrix
soll möglichst genaue Resultate liefern. Dazu könnte man die Spalten-
14

2.2 Generischer LR-Zerlegungs-Algorithmus
und/oder Zeilenpivotsuche einsetzen und stets nur das betragsmäßig größte Element
einer Zeile oder Spalte als Pivot akzeptieren, wie in 2.1 beschrieben. Dies würde jedoch
die Menge der möglichen Pivots zu sehr einschränken, da man ja auch den Fill
möglichst gering halten will. Deshalb wählt man den flexibleren Ansatz des threshold
pivoting (etwa “Schwellwertpivotsuche”) [9], wobei man nur Nichtnullelemente a i j
als potentielle Pivots zuläßt, die die threshold condition (“Schwellwertbedingung”)
erfüllen, die definiert ist als
|a i j | ≥ u ⋅ max
c∈J |a ic|, (2.16)
wobei 0 ≤ u ≤ 1 ein Programmparameter ist. Solche Elemente heißen im weiteren
akzeptabel.
Auswahl des Pivotelements Der in dieser Arbeit eingesetzte Algorithmus zur Auswahl
eines Pivotelements, dargestellt in Algorithmus 2.2, setzt Threshold pivoting zur
Sicherung der numerischen Stabilität sowie eine Variante der Markowitz Strategie zur
Reduktion des Fill ein [25, 23]. Es wird dabei ein akzeptables Element der aktiven
Submatrix gesucht, dessen Markowitz-Zahl möglichst klein ist.
Analog zu Algorithmus 2.1 werden Mengen I′ und J′ von Zeilenindizes bzw. Spaltenindizes
definiert, die zunächst alle Indizes der Zeilen bzw. Spalten der aktiven Submatrix
enthalten. Diese werden sukzessive um die Indizes von bereits nach möglichen
Pivots untersuchten Zeilen bzw. Spalten verkleinert. Da die Suche nach Pivots in allen
Zeilen und Spalten zu aufwendig wäre, beschränkt man die Suche auf P Zeilen oder
Spalten, d. h. es wird nacheinander jeweils die Zeile oder Spalte ausgewählt, die die
geringste Anzahl an Nichtnullelementen hat und darin nach akzeptablen Pivotkandidaten
gesucht. Dies wird fortgesetzt bis insgesamt P Zeilen und Spalten untersucht
wurden.
Bei Versuchen mit dem im Rahmen dieser Arbeit entstandenen Programm ergab
sich P = 4 als Wert, der konsistent gute Ergebnisse liefert, die durchschnittlich am
wenigsten vom experimentellen Optimum abweichen, so daß P = 4 auch als default-
Wert gewählt wurde.
Es ist jedoch möglich, daß auch nach P Schritten kein Kandidat gefunden wurde,
der die Schwellwertbedingung (2.16) erfüllt, da diese eine zeilenweise Bedingung
ist und u. U. ausschließlich Spalten untersucht wurden. In diesem Fall wird einfach
solange in den nächstdünnbesetzten Zeilen oder Spalten weitergesucht, bis ein akzeptabler
Kandidat gefunden wurde.
Andererseits ist es auch möglich, daß während der Suche ein optimaler Kandidat
gefunden wird, d. h. ein solcher, dessen Markowitz-Zahl minimal bezüglich der akti-
15

2 Lösung linearer Gleichungssysteme
ven Submatrix ist. In diesem Fall wird die Suche abgebrochen und das Element sofort
ausgewählt.
I′:= I;
J′:= J;
n:= 1;
best:= ⊥;
M best := −1;
repeat
Wähle i ∈ I′ oder j ∈ J′ mit minimaler Anzahl von Nichtnullelementen
for all a i j ≠ 0 in dieser Zeile oder Spalte do
if a i j akzeptabel? then
if M i j minimal? then
Wähle a i j als Pivot aus
else if best = ⊥ ∨ M i j < M best then
best:= a i j ;
M best := M i j ;
end if
end if
end for
I′:= I′n{i}; oder J′:= J′n{ j};
n:= n + 1;
until n > p ∧ best ≠ ⊥;
Wähle best als Pivot aus
Algorithmus 2.2: Auswahl eines Pivotelements
16

3 Parallele LR-Zerlegung
Um bestimmte Designentscheidungen nachvollziehbar zu machen, soll in diesem Kapitel
zunächst eine Klärung der dem Programm zugrundeliegenden Bedingungen in
Form von Hard- und Software erfolgen. Anschließend soll, ausgehend von dem in
Kapitel 2 beschriebenen sequentiellen Algorithmus zur LR-Zerlegung und den unten
dargestellten Voraussetzungen, die Entwicklung eines parallelen Algorithmus erläutert
werden. Im letzten Abschnitt dieses Kapitels werden die mit diesem Algorithmus
erzielten Ergebnisse diskutiert.
3.1 Der massiv-parallele Rechner Cray T3D
Der T3D [16] ist ein MIMD (Multiple Instruction Multiple Data) Rechner mit verteiltem
Speicher (distributed memory), der aber logisch global addressierbar ist. Das
bedeutet, daß jeder Prozessor eine separate Folge von Instruktionen auf einem eigenen
lokalen Speicher ausführt.
Dies unterscheidet ihn von Vertretern anderer Parallelrechnermodelle, wie SIMD
(Single Instruction Multiple Data), bei dem alle Prozessoren von einem einzigen Instruktionsstrom
gesteuert auf verschiedenen Daten operieren, sowie von Multiprozessor-Rechnern
(oder MIMD-Rechnern mit gemeinsamem Speicher), bei denen nur ein
physikalischer Speicher für alle Prozessoren zu Verfügung steht.
Von vielen distributed-memory MIMD Rechnern unterscheidet sich der T3D außerdem
dadurch, daß er über einen globalen Adreßraum verfügt, weshalb Zugriffe auf
den Speicher verschiedener Prozessoren direkt möglich sind, was bei anderen Rechnern
häufig nur mittels Message Passing geschehen kann, bei dem der Zugriff nicht
vom Empfänger initiiert werden kann und kein asynchrones Empfangen möglich ist.
Diese Eigenschaft des T3D spielt bei dem für diese Arbeit entstandenen Programm
insofern eine wichtige Rolle, als daß die eingesetzten Kommunikationsroutinen davon
Gebrauch machen und so ein effizienter asynchroner Datenaustausch möglich wird.
Abbildung 3.1 veranschaulicht die Klassifizierung noch einmal.
Eine CPU und der dazugehörige lokale Speicher bilden beim T3D ein processor
17

3 Parallele LR-Zerlegung
element (PE). Die CPU ist ein superskalarer 64bit-RISC-Prozessor vom Typ DEC Alpha,
der mit 150 MHz getaktet ist. Jedes PE besitzt einen Speicher von 64 MB. Im
Cray T3D ist die Netzwerktopologie ein dreidimensionaler Torus. Die Datenkanäle
sind bidirektional und arbeiten in x-, y- und z-Richtung unabhängig voneinander.
Der Zielrechner cray des Konrad-Zuse-Zentrums Berlin verfügt über 256 PEs, die in
einem 4 × 4 × 8 Torus angeordnet sind, wobei 2 PEs jeweils zu einem Rechenknoten
zusammengeschlossen sind. Mehrere PEs bilden eine Partition, deren Größe stets eine
Potenz von 2 sein muß. Die maximale Transferrate beim Verschicken von Daten von
einem PE zu einem anderen beträgt ungefähr 100 MB/s bei einer Latenzzeit (Startup-Zeit,
d. h. Kommunikationszeit, die unabhängig vom Datenvolumen benötigt wird)
von unter 1µs.
3.2 Paralleles Programmiermodell
Obwohl der T3D ein MIMD-Rechner ist, wird jedoch ein Single Program Multiple
Data (SPMD) Programmiermodell implementiert, das eine leichte Abschwächung
des MIMD-Ansatzes mit sich bringt, d. h. jedes PE führt dasselbe Programm aus,
operiert jedoch auf unterschiedlichen Daten. Die einzelnen PEs sind durch logische
PE-Nummern von 0 bis p − 1 identifizierbar, wobei p die Anzahl der PEs darstellt.
Um eine maximale Ausnutzung der Hardware des T3D sowie eine möglichst hohe
Nebenläufigkeit zu erzielen, wurde ein kontrollparalleles Programmiermodell unter
Benutzung der SHMEM-Bibliothek [3] anderen Ansätzen vorgezogen.
Im Gegensatz zu einem kontrollparallelen Programmiermodell nutzt ein datenparalleles
nur die Nebenläufigkeit, die aus der Verteilung von Daten resultiert. Dies
geschieht meist durch Programmierung in einer speziellen datenparallelen Sprache,
deren Compiler dann den Kommunikationscode automatisch generiert. Dies ist natürlich
wesentlich weniger fehleranfällig und leichter zu entwerfen als handgeschriebener
(kontrollparalleler) Code.
Auch an kontrollparallelen Programmiermodellen gibt es eine gewisse Auswahl.
Ein weit verbreitetes ist Message Passing, wobei eine logische Unterteilung des Programms
in tasks vorgenommen wird, die Nachrichten (Messages) über channels kommunizieren.
Solche Modelle sind häufig sehr portabel (z. B. die MPI Bibliothek [15]),
stellen jedoch nur eine geringfügig höhere Abstraktion als die hardwarespezifischen
Kommunikationsroutinen (wie z. B. SHMEM) dar, weshalb sie gerne für general purpose
Software oder ad-hoc Lösungen eingesetzt werden. Aufgrund ihrer unspezifischen
Ausrichtung sind sie jedoch oftmals langsamer als hardwarenähere Modelle.
Für die SHMEM-Routinen wird z. B. eine Latenzzeit von unter 1µs angegeben, für die
Message Passing Routinen (PVM) dagegen 2–10µs (das sind bis zu 1500 Taktzyklen).
18

3.3 Eingesetzte Funktionen und Klassen
Verbindungsnetzwerk
Memory Memory Memory
CPU CPU CPU
SIMD Rechner
Instruktionsfolge
Verbindungsnetzwerk
Memory Memory Memory
CPU CPU CPU
Adreßraum
Cray T3D
Speicherorganisation
Verbindungsnetzwerk
CPU CPU CPU
Memory
Memory Memory Memory
MIMD mit lokalem Adreßraum
CPU CPU CPU
Shared-memory MIMD Rechner
Abbildung 3.1: Verschiedene Modelle von Parallelrechnern
3.3 Eingesetzte Funktionen und Klassen
Neben den unten beschriebenen Klassen und Funktionen wurde ein TCL-Skript, das
zu Beginn entstand, erfolgreich eingesetzt, welches den Output der einzelnen PEs in
verschiedenen Fenstern anzeigt.
19

3 Parallele LR-Zerlegung
Die SHMEM Bibliothek Die SHMEM-Bibliothek [3] stellt Funtionen zur Kommunikation
von Daten sowie zur Synchronisation bereit. Die wichtigsten Funktionen
sind:
shmem_get(long *target, long *source, int nlong, int pe);
shmem_put(long *target, long *source, int nlong, int pe);
wobei
target Zieladresse (lokal bei shmem_get, entfernt 1 bei shmem_put)
source Quelladresse (entfernt bei shmem_get, lokal bei shmem_put)
nlong Anzahl der 64bit-Worte, die übertragen werden sollen
pe logische Nummer des PE, mit dem kommuniziert werden soll
shmem_put schreibt nlong 64bit-Worte von source des aufrufenden PE in den Speicher
des PE, das durch pe identifiziert ist, an die Adresse target. Das Schreiben
erfolgt asynchron, das entfernte PE wird nicht von der Operation informiert.
shmem_get liest nlong 64bit-Worte aus dem Speicher des PE, das durch pe identifiziert
ist, von der Adresse source und schreibt sie in den Speicher des aufrufenden
PE an die Adresse target.
shmem_put ist dabei wesentlicher schneller als shmem_get, so daß, wann immer
möglich, erstere Routine eingesetzt werden sollte.
Beim T3D wird bei remote writes (shmem_put) nicht auf die Kohärenz des Cache
geachtet, so daß u. U. veraltete Daten aus dem Cache gelesen werden. Es hat
sich deshalb als angemessen erwiesen, das remote write invalidate bit zu Beginn des
Programms zu setzen und nicht wieder zu löschen. Dadurch wird bei jedem Remote
write automatisch die betroffene Cache line ungültig.
Die wichtigste Funktion zur Synchronisation von PEs ist der barrier-Mechanismus,
der eine Fortführung des Programms erst bei Erreichen aller PEs des Synchronisationspunktes
(Barrier) ermöglicht. Die SHMEM-Bibliothek stellt hierzu eine Funktion
shmem_barrier zur Verfügung. Daneben ist eine zweiseitige Synchronisation
über ein spin-wait auf eine Adresse, an die ein anderes PE schreibt, einfach zu realisieren.
1 d. h. zur Laufzeit nicht lokal.
20

3.3 Eingesetzte Funktionen und Klassen
Die Klasse DistrObj Die Klasse DistrObj (“distributed objects”) [22] stellt
Kommunikations-, Synchronisations- sowie Reduktionsmethoden bereit, die eine Kooperation
der auf verschiedenen PEs kreierten Objekte der Klasse (oder typischerweise
einer davon abgeleiteten) ermöglichen. Weiterhin ist das Unterteilen der Menge
von beteiligten PEs möglich, so daß eine problemorientierte Aufteilung der Prozessoren
gewährleistet wird, indem die gleichförmige Sicht auf einen “kleineren” Parallelrechner
angeboten wird (d. h. Numerierung von 0 bis ¯p − 1, wobei ¯p = 2 i ≤ p).
DistrObj stellt seine Methoden auch als globale Funktionen zur Verfügung, so daß
das Programm zu Beginn als großes DistrObj verstanden werden kann, das alle PEs
der zur Verfügung stehenden Partition umfaßt. Hiervon können dann mittels der Funktion
partition kleinere DistrObjs kreiert werden. Diese wird folgendermaßen eingesetzt:
DistrObj partition(int first, int stride, int size) const;
wobei
first Nummer des ersten PE des neuen DistrObj
stride 2 stride ist die Schrittweite der PE-Nummern
size Anzahl der PEs im neuen DistrObj
Die wichtigste Kommunikationsform der Klasse DistrObj wird mittels der Methode
gossip bereitgestellt. Unter gossipping (“tratschen”) versteht man das kollektive
Austauschen von verteilten Daten, die mittels einer bestimmten Operation zusammengeführt
werden und nach Beendigung des Gossips allen PEs zur Verfügung stehen.
Die Kommunikationsstruktur der gossip-Methode der Klasse DistrObj ist ein
Hypercube [11, Kapitel 11]. Es werden also log 2 p Schritte zum Zusammenführen
aller Daten benötigt. Zum Austauschen der Daten werden Routinen der SHMEM-
Bibliothek genutzt. Abbildung 3.2 veranschaulicht dies noch einmal für eine PE-
Anzahl von 8. Die Methode gossip sieht konkret folgendermaßen aus:
void gossip(MsgBuffer &data, MsgBuffer &work,
GossipFunction gf);
wobei
data lokaler Teil der verteilten Daten
work Arbeitsbereich, in den entfernte PEs ihre Daten schreiben
21

3 Parallele LR-Zerlegung
6 7
2 3
Schritt 2
4 5
Schritt 3
0 1
Schritt 1
Abbildung 3.2: Kommunikationsschritte der Methode gossip
gf Funktion zum Zusammenführen der Daten
Eine GossipFunction hat folgendes aussehen:
typedef void (DistrObj::*GossipFunction)(int stage,
MsgBuffer &local,
MsgBuffer &received);
In local werden die mittels der spezifizierten Funktion aus den lokalen Daten local
und den empfangenen received zusammengeführten Informationen wieder abgelegt
und im nächsten Schritt (stage+1) an ein weiteres PE gesandt.
Weitere benutzte Klassen Neben den oben umrissenen Klassen bzw. Funktionsbibliotheken
existieren noch weitere Klassen und Funktionen, die den Umgang mit
dünnbesetzten Matrizen erleichtern. Diese entstammen allesamt der Klassenbibliothek,
die im Rahmen von [22] entstand. Besonders wichtig sind im Zusammenhang
mit der vorliegenden Arbeit die Klassen SVector (“sparse vector”) und SVSet (“sparse
vector set”). Ein SVector beschreibt einen dünnbesetzten Vektor, dessen Elemente
je einen Index sowie einen numerischen Wert besitzen. Ein SVSet ermöglicht
es, die Elemente einer Anzahl von SVectors in einem großen zusammenhängenden
Speicherblock zusammenzufassen, die jeweils über einen Index erreichbar sind, so
daß man somit eine dünnbesetzte Matrix beschreiben kann. Der Speicherblock kann
22

3.4 Der parallele Algorithmus
dynamisch vergrößert werden und so neue Elemente sowie Vektoren hinzugefügt werden.
Weiterhin stehen noch die Klassen Array sowie DataArray zur Verfügung, die
beide dynamische Arrays implementieren, wobei Array zur Speicherverwaltung die
C++-Operatoren new und delete verwendet, also leicht ineffizienter ist als die nicht
C++-konforme Klasse DataArray, welche realloc() verwendet.
3.4 Der parallele Algorithmus
Das Design paralleler Algorithmen ist kein Prozeß, der sich an simplen Rezepten orientiert.
Es verlangt vielmehr einen großen Anteil kreativen Denkens, kann jedoch von
einer methodischen Herangehensweise profitieren, die den Entscheidungsfindungsprozeß
gliedert. Die Entscheidungen, die während der Entwicklung des parallelen
Algorithmus dieser Arbeit getroffen werden mußten, sollen unter Verwendung der
PCAM-Methode [11, Kapitel 2] dokumentiert werden, die im ersten Unterabschnitt
vorgestellt wird. Dies wird jedoch nur bis zu einem Grade durchgeführt, der auf
diesem Abstraktionsniveau sinnvoll erscheint. Es bleiben also noch wesentliche Designentscheidungen
offen, die im nächsten Abschnitt diskutiert werden.
3.4.1 Die PCAM-Methode
Der Name der PCAM-Methode rührt von den Anfangsbuchstaben ihrer 4 Einzelschritte
her:
1. Partitionierung (“partitioning”). Die Berechnung und die Daten, auf denen
während dieser Berechnung operiert wird, werden möglichst fein unterteilt.
Praktische Aspekte wie die Zahl der Prozessoren werden ignoriert, stattdessen
konzentriert man sich auf die Erkennung potentieller Möglichkeiten der parallelen
Ausführung.
2. Kommunikation (“communication”). Die zur Koordination der Teilberechnungen
nötige Kommunikation wird bestimmt und angemessene Kommunikationsstrukturen
sowie Algorithmen definiert.
3. Agglomeration (“agglomeration”). In diesem Schritt werden Teilberechnungen
zu größeren zusammengefaßt, indem man auf praktische Gesichtspunkte eingeht
mit dem Ziel einfacherer Implementation und erhöhter Performance durch
weniger Kommunikation.
23

3 Parallele LR-Zerlegung
4. Abbildung (“mapping”). Jede Teilberechnung wird einem Prozessor zugewiesen.
Die Abbildung kann statisch geschehen oder zur Laufzeit durch Loadbalancing
Algorithmen bestimmt werden.
Für jede der einzelnen Phasen gibt es verschiedene Herangehensweisen. Bei der
Partitionierung z. B. unterscheidet man zwischen domain decomposition sowie functional
decomposition. Erstere Technik konzentriert sich zunächst auf die Unterteilung
der an der Berechnung beteiligten Daten und anschließend auf die Zuordnung der Berechnung
zu den Daten. Bei der Functional decomposition geht man komplementär
vor, d. h. man unterteilt zunächst die Berechnungsschritte und kümmert sich dann um
die damit verbundenen Daten.
Die zwischen den einzelnen Teilaufgaben (Tasks) notwendigen Kommunikationsstrukturen
kann man wie folgt kategorisieren:
• Bei lokaler Kommunikation kommuniziert ein Task nur mit einer kleinen Menge
von anderen Tasks, bei globaler Kommunikation mit vielen anderen Tasks.
• Bei strukturierter Kommunikation sind die einzelnen Tasks in einer regulären
Struktur angeordnet, z. B. einem Baum, bei unstrukturierter in einem beliebigen
Graph.
• Bei statischer Kommunikation ändert sich die Identität der Kommunikationspartner
in Form von Tasks nicht während der Laufzeit, bei dynamischer Kommunikation
u. U. schon.
• Bei synchroner Kommunikation kooperieren sendende und empfangende Tasks
miteinander, bei asynchroner Kommunikation finden Kommunikationsvorgänge
ohne Beteiligung eines der beiden Partner statt. Dabei muß zwischen der
Sende- und der Empfangsphase unterschieden werden. Beide können unabhängig
voneinander entweder synchron oder asynchron sein.
In den ersten beiden Phasen wird eine i. allg. zu feinkörnige Aufteilung der Berechnung
vorgenommen. Durch Erhöhung der Granularität (Zusammenfassung von
Teilberechnungen) versucht man deshalb in der Agglomerationsphase, eine adäquatere
Anpassung an den geplanten Einsatzbereich (sprich die zur Verfügung stehende
Hardware) zu erreichen. Dabei muß aber auch berücksichtigt werden, daß die damit
erzielte Granularität nicht wieder zu groß ist, so daß dies der Skalierbarkeit, d. h.
der Ausnutzung von mehr Nebenläufigkeit bei Einsatz von mehr PEs, im Wege steht.
Entwickelt man beispielsweise auf 4 PEs und agglomeriert die Berechnung in ebensoviele
Teilberechnungen, so bringt dies evtl. eine gute Performancesteigerung; plant
24

3.4 Der parallele Algorithmus
man jedoch dann den Einsatz bei z. B. 128 PEs, so wird ein Großteil des Rechenpotentials
ungenutzt bleiben.
In der Abbildungsphase versucht man, die Parallelität durch Plazierung nebenläufiger
Tasks auf verschiedenen Prozessoren zu erhöhen sowie Lokalität durch Plazierung
häufig kommunizierender Tasks auf einem Prozessor zu verbessern.
3.4.2 Partitionierung
Bei der Partitionierung bietet sich die Domain decomposition an. Gemäß der Forderung,
möglichst viel Parallelismus auszunutzen, wird die zu faktorisierende Matrix
vollständig aufgeteilt, so daß ein Task genau ein Element der Matrix bearbeitet. Betrachtet
man Algorithmus 2.1, so fällt auf, daß sich dadurch beide inneren Schleifen,
die L- sowie die Update-loop parallelisieren lassen. Weiterhin ermöglicht diese Aufteilung
die Parallelisierung beider Schleifen von Algorithmus 2.2, der Pivotauswahl.
Dies läßt von allen Schleifen des Algorithmus lediglich die äußerste, die Pivotloop,
als nicht parallelisierbar aufgrund der Partitionierung anhand der Daten übrig.
Diese Schleife ist inhärent sequentiell, da die aktive Submatrix im Schritt s von den
Updates in Schritt s − 1 abhängt. Im Worst case, d. h. komplett dichte Pivotzeile und
-spalte in Schritt s−1, verändern sich alle Elemente der in Schritt s aktiven Submatrix
in der Update-loop von Schritt s − 1. Für dünnbesetzte Matrizen ist dies jedoch selten
der Fall. Es ist deshalb sehr wohl möglich, mehrere Schritte der Pivot-loop zu einem
parallelen zusammenzufassen, wenn kompatible (oder auch unabhängige) Elemente
als Pivots ausgewählt werden. Zwei Elemente a i j und a kl heißen kompatibel und
können simultan eliminiert werden, falls gilt
a il = a k j = 0. (3.1)
Die Elemente a i j und a kl der Matrix
264a i
. .
kl375
j0 0a kl375 264a i j0
a k ja
sind also kompatibel, die der Matrix
.
.
25

3 Parallele LR-Zerlegung
hingegen nicht.
Wählt man bei der Durchführung von Algorithmus 2.1 a (s)
i s j s
als Pivotelement, das
zu a (s)
k s l s
kompatibel sei, so ergeben sich keine Updates für a (s)
k s j
, d. h.
¯l ks j s
= a (s)
k s j s=a (s)
i s j s
= 0 ⇒ a (s+1)
k s j
= a (s)
k s j . (3.2)
Des weiteren ergeben sich keine Updates für a (s)
il s
, d. h.
a (s)
i s l s
= 0 ⇒ a (s+1)
il s
= a (s)
il s
. (3.3)
Wählt man stattdessen a (s)
k s l s
als Pivotelement, so entstehen keine Updates für a (s)
i s j
, d. h.
¯l is l s
= a (s)
i s l s=a (s)
k s l s
= 0 ⇒ a (s+1)
i s j = a (s)
i s j . (3.4)
Außerdem entstehen keine Updates für a (s)
i j s
, d. h.
a (s)
k s j s
= 0 ⇒ a (s+1)
i j s
= a (s)
i j s
. (3.5)
Wählt man beide Elemente als Pivots aus und führt zuerst die L-loop für a (s)
i s j s
aus und
anschließend für a (s)
k s j s
, dann ergibt sich folgendes:
¯l i js := a (s)
i j s=a (s)
i s j s
¯l ils := a (s+1)
il s=a (s+1)
k s l s
.
Wegen (3.3) ergibt sich
¯l ils := a (s)
il s=a (s)
k s l s
.
Führt man hingegen die L-loop zuerst für a (s)
k s l s
und anschließend für a (s)
i s j s
aus, so ergibt
sich folgendes:
¯l ils := a (s)
il s=a (s)
k s l s
¯l i js := a (s+1)
i j s=a (s+1)
i s j s
.
26

3.4 Der parallele Algorithmus
Wegen (3.5) folgt
¯l i js := a (s)
i j s=a (s)
i s j s
,
also dasselbe Ergebnis wie bei umgekehrter Ausführungsreihenfolge. Führt man zuerst
die Update-loop für a (s)
i s j s
aus und dann für a (s)
k s l s
, so ergibt sich folgendes:
a (s+1)
i j := a (s)
i j − ¯l i js ⋅ a (s)
i s j
a (s+2)
i j
:= a (s+1)
i j
Wegen (3.2) folgt
a (s+2)
i j
− ¯l ils ⋅ a (s+1)
k s j
= a (s)
i j
− ¯l i js ⋅ a (s)
i s j − ¯l ils ⋅ a (s)
k s j .
= a (s)
i j − ¯l i js ⋅ a (s)
i s j − ¯l ils ⋅ a (s+1)
k s j
.
Führt man die Update-loop in umgekehrter Reihenfolge aus, so ergibt sich
a (s+1)
i j
:= a (s)
i j
− ¯l ils ⋅ a (s)
k s j
a (s+2)
i j
:= a (s+1)
i j
und wegen (3.4)
− ¯l i js ⋅ a (s+1)
i s j
= a (s)
i j
− ¯l ils ⋅ a (s)
k s j − ¯l i js ⋅ a (s+1)
i s j
a (s+2)
i j = a (s)
i j − ¯l i js ⋅ a (s)
i s j − ¯l ils ⋅ a (s)
k s j .
Aus diesem Grund ist die Update-Operation bei kompatiblen Pivots kommutativ, d. h.
die aus a i j resultierenden Updates können vor oder nach den Updates von a kl ausgeführt
werden, ohne daß sich an der aktiven Submatrix des nächsten Eliminationsschrittes
etwas ändert (bis auf die
375
unvermeidlichen Rundungsfehler). Kompatibilität
läßt sich durch Induktion auf eine Anzahl von Pivots m erweitern, die dann (im permutierten
Zustand) eine m-dimensionale Diagonalmatrix der Form
0
.
0 a i2 j ..
2
.
.
. .. . .. 0
0 0 a im j m
.
.
..
264a i1 j 1
0
bilden. Um maximale Parallelität zu nutzen, wird zunächst gefordert, möglichst viele
kompatible Pivots in einem Schritt zu eliminieren.
27

3 Parallele LR-Zerlegung
3.4.3 Kommunikation
Ein hoher Kommunikationsaufwand ist für die Phase der Pivotauswahl vonnöten.
Um Algorithmus 2.2 ausführen zu können, ist es einerseits nötig, die Markowitz-
Zahlen sowie das für die Überprüfung des Threshold-Kriteriums notwendige Maximalelement
zu bestimmen. Dies erfordert stets eine globale, synchrone Kommunikation,
da die hierzu erforderlichen Daten (die r i und c j aus (2.15) sowie das “Wissen”
über das Maximalelement) auf viele Tasks verteilt sind und von vielen benötigt
werden. Aus diesem Grund bietet sich hier der Einsatz der kooperativen Methode
gossip an, mittels derer dieser Kommunikationsvorgang effizient gestaltet werden
kann. In jedem Eliminationsschritt ändern sich jedoch einige, aufgrund der dünnbesetzten
Struktur häufig nur wenige der Daten durch Verkleinerung der aktiven Submatrix,
Erzeugung von Fill-in sowie Änderung der Werte der Nichtnullelemente durch
Updates, weshalb man das Kommunikationsvolumen gering hält, indem man nur Änderungen
an den Faktoren der Markowitz-Zahlen (d. h. den rowcounts und columncounts)
sowie geänderte Maximalelemente überträgt.
Da mehrere kompatible Pivots in einem Schritt eliminiert werden sollen, ist es
nötig, Informationen über die Kompatibilität bzw. Inkompatibilität mehrerer Elemente
zu erlangen. Dies ist nicht anders zu bewerkstelligen, als die Elemente, die eine
Inkompatibilität verursachen könnten, zu überprüfen. Für zwei Elemente a i j und a kl
bedeutet dies, daß die Elemente a il und a k j auf den Wert 0 hin getestet werden müssen.
Erst wenn dies geschehen ist, ist erwiesen (oder widerlegt), daß die Elemente a i j
und a kl kompatibel sind. Deshalb muß hier eine globale, synchrone Kommunikation
stattfinden, an der alle Tasks beteiligt sind, deren Elemente auf gegenseitige Kompatibilität
überprüft werden sollen. Für m Elemente bedeutet dies einen zeitlichen
Aufwand vonO (m 2 ). Auch hier kann die Methode gossip zur effizienten Kommunikation
eingesetzt werden.
Betrachtet man Algorithmus 2.1, so erkennt man, daß zur Durchführung der
Update-loop beim Update von Element a i j der Wert des Elementes ¯l i js sowie der
des Elementes a is j benötigt wird, die, ausgehend von der im Partitionierungsschritt
gewählten Struktur, nicht auf dem Task von Element a i j residieren. Aus diesem
Grund ist hier eine Kommunikation nötig, deren Struktur asynchron ist, da die Tasks,
denen die benötigten Elemente zugeordnet sind, nicht an dem Kommunikationsvorgang
beteiligt werden müssen, weshalb sich die direkte Verwendung von Routinen
der SHMEM-Bibliothek anbietet.
Geht man von sehr dünnbesetzten Matrizen aus, wie sie in der linearen Programmierung
vorkommen, so läßt sich der Kommunikationsaufwand erheblich reduzieren,
wenn man Zeilen und Spalten mit nur einem Nichtnullelement gesondert behandelt.
Solche Elemente heißen singletons. Für Einzelelemente in Zeilen (row singletons)
28

3.4 Der parallele Algorithmus
muß lediglich die L-loop durchgeführt werden (potentielle Nichtnullelemente in der
Spalte), jedoch nicht die Update-loop, da alle a is j = 0 mit j ≠ j s . Für Einzelelemente in
Spalten (column singletons) entfallen sowohl L- als auch Update-loop, da alle ¯l i js = 0
mit i ≠ i s . Singletons sind generell kompatibel, da keine Updates entstehen. Natürlich
würden diese Elemente auch bei einer “normalen” Pivotauswahl bevorzugt behandelt
(M i j = 0), jedoch würde ein unnötig hoher Kommunikations- und Rechenaufwand entstehen,
der durch die gesonderte Behandlung vor der “eigentlichen” Faktorisierung
vermieden werden soll.
3.4.4 Agglomeration und Abbildung
Zu Zwecken der Agglomeration böte es sich an, Elemente einer Zeile oder Spalte zusammenzufassen,
da so die Kommunikation zum Bestimmen des Maximalelementes
einer Zeile oder Spalte, das zur Überprüfung der Threshold condition in Algorithmus
2.2 notwendig ist, sowie zur Ermittlung des Rowcounts bzw. des Columncounts,
der zur Bestimmung der Markowitz-Zahlen benötigt wird, entfiele. Bei einer zeilenweisen
Verteilung der Matrixelemente ginge jedoch Nebenläufigkeit verloren, da die
Kommunikation von Informationen einer Zeile, wie z. B. das Verschicken aller Elemente
a is j einer Pivotzeile, die zur Durchführung der Update-loop in Algorithmus 2.1
benötigt werden, stets nur von einem Task ausginge. Dies hätte zwar den Vorteil, daß
insgesamt nur wenige Kommunikationsschritte notwendig wären, was sich bei einer
Architektur mit hohen Latenzzeiten auszahlen würde. Da der T3D jedoch besonders
geringe Latenzzeiten im Vergleich zu anderen Architekturen aufweist (siehe 3.1), wird
hier eine grid distribution (oder auch cyclic oder scattered distribution) gewählt. Für
p = XY Prozessoren ist sie definiert durch die Abbildung
a i j → Prozessor q = ( j mod X + (i mod Y) ⋅ X), ∀i, j: i, j ∈ {0,:::,n
− 1}, (3.6)
wenn man die p Prozessoren in einem X ×Y-Gitter anordnet und sie von 0 bis XY − 1
durchnumeriert. Abbildung 3.3 zeigt eine 4×4-Matrix, die auf 4 Prozessoren in einem
2 × 2-Gitter verteilt wurde.
Die Grid distribution führt zu einer optimalen Load balance und hat eine geringe
Kommunikationskomplexität für die LR-Zerlegung dichtbesetzter Matrizen. Dies impliziert,
daß beim Algorithmus für dünnbesetzte Matrizen jeder Prozessor ungefähr
dieselbe Anzahl an (Null- oder Nichtnull-) Elementen zugewiesen bekommt. Falls
sich für eine gegebene Matrix die statistische Annahme bewahrheitet, daß jedes Element
der Matrix die gleiche Wahrscheinlichkeit hat, den Wert 0 zu besitzen, dann folgt
daraus, daß die Nichtnullelemente gleichmäßig über die zur Verfügung stehenden Prozessoren
verteilt werden. Falls diese Annahme nicht zutrifft, weil Nichtnullelemente
29

3 Parallele LR-Zerlegung
0 1 2 3
0
1
2
3
0 1 0 1
2 3 2 3
0 1 0 1
2 3 2 3
Abbildung 3.3: Beispiel einer grid distribution
sich an bestimmten Stellen der Matrix häufen, z. B. in der rechten unteren Ecke oder in
dichtbesetzten Untermatrizen, dann werden diese Häufungselemente über viele Prozessoren
verteilt, und so wieder ein guter Lastausgleich erreicht. Die Speicherausnutzung
profitiert ebenfalls von dieser Aufteilung, da es unwahrscheinlich ist, daß ein
Prozessor keinen Platz mehr für neue Elemente hat, während andere noch viel freien
Speicher besitzen.
Eine Alternative zu Matrix-unabhängigen Verteilungsverfahren sind solche, die
Wissen über das Muster von Nichtnullelementen ausnutzen, um eine optimale Lastverteilung
zu erreichen. Das Muster der Nichtnullelemente ändert sich jedoch in jedem
Eliminationsschritt. Eine Anpassung an diese Veränderungen würde jedoch eine
ständige Umverteilung von Elementen erfordern, die zusätzlichen Kommunikationsaufwand
erfordert (und Rechenaufwand zur Analyse des Musters), so daß eine solche
Verteilung, besonders im Hinblick auf sehr dünnbesetzte Matrizen, bei deren Faktorisierung
der Rechenaufwand schon den Kommunikationsaufwand unterschreiten kann,
nicht in Betracht kommt.
Im Partitionierungsschritt wurde gefordert, möglichst viele kompatible Pivots in
einem Schritt zu eliminieren, um die Nebenläufigkeit besser auszunutzen. Dies hat jedoch,
wie sich bei der Analyse der Kommunikationsstruktur herausstellte, den Nachteil
der stark vergrößerten Kommunikationskomplexität bei der Pivotauswahl (O (m 2 )
für die Kompatibilitätsbestimmung von m Pivotkandidaten). Deshalb wird die Anzahl
der in einem Schritt eliminierbaren Pivots auf eine “kleine” Zahl begrenzt.
Durch Fill-in wird die aktive Submatrix in jedem Schritt dichter. Aus diesem
Grund kann es ab einer bestimmten Dichte günstiger sein, auf die parallele Elimination
von mehreren Pivots zu verzichten und statt dessen nur ein Element pro Schritt zu
30

3.5 Die Klasse DSLUFactor
eliminieren, was den Aufwand zur Kombatibilitätsbestimmung spart.
Der parallele Algorithmus zur LR-Zerlegung ist in Algorithmus 3.1 wiedergegeben.
Verteile Matrix anhand der Grid distribution
while Row singletons vorhanden sind do
Eliminiere Row singletons
end while
while Column singletons vorhanden sind do
Eliminiere Column singletons
end while
while Dimension der aktiven Submatrix > 0 do {Faktorisierung des Nukleus}
if aktive Submatrix dünnbesetzt? then
Wähle Menge kompatibler Pivots und eliminiere sie
else
{aktive Submatrix dichtbesetzt}
Wähle Pivot und eliminiere ihn
end if
end while
Algorithmus 3.1: Paralleler Algorithmus zur LR-Zerlegung
3.5 Die Klasse DSLUFactor
Die in dieser Arbeit entstandene Klasse DSLUFactor setzt den parallelen Algorithmus
zur LR-Zerlegung um. Sie ist eine abgeleitete Klasse von DistrObj, die als
Inputinterface die Methode
int DSLUFactor::factor(const SVector *r[], int dimension,
int nnzero);
zur Verfügung stellt, wobei
r die zu faktorisierende Matrix als zeilenweises Array von SVectors
dimension die Dimension (n) der Matrix
nnzero die Gesamtanzahl der Nichtnullelemente in der Matrix
Der Rückgabewert ist negativ, falls die Matrix singulär ist, d. h. keine eindeutige Lösung
für Ax = b mit der zu faktorisierenden Matrix als A existiert.
31

3 Parallele LR-Zerlegung
3.5.1 Datenverteilung
Die Datenverteilung geschieht in der Funktion DSLUFactor::factor selbst, und
zwar exakt nach der oben beschriebenen grid distribution. Die Aufteilung mittels der
Grid distribution wird zusätzlich durch zwei Unterklassen (“nested classes”) DSLURow
und DSLUCol unterstützt, die ebenfalls abgeleitete Klassen von DistrObj sind, und so
partitioniert, daß sie für das eigene 2 PE die eingeschränkte Sicht auf die PEs ermöglicht,
denen jeweils dieselben Zeilen bzw. Spalten der Matrix zugeordnet sind (die
also im Prozessorgitter dieselbe Zeile oder Spalte bilden, siehe Abbildung 3.3). In
diesen Klassen werden auch alle Daten verwaltet, die sich ausschließlich auf Zeilen
resp. Spalten beziehen, z. B. die Permutationsvektoren π und ρ.
Alle dem eigenen PE zugeordneten Nichtnullelemente werden dazu in ein SVSet
kopiert, das vorher auf die Größe nnzero mal einem bestimmten Faktor gebracht
wurde. Dieses initiale Vergrößern hat zwar nur spekulativen Charakter, reicht aber in
den meisten Fällen aus, um nicht (oder nur selten) während der Faktorisierung neuen
Speicher allokieren zu müssen (was sehr kostenintensiv sein kann). Dabei werden
alle Elemente doppelt gehalten, d. h. im Objekt der Klasse DSLURow befinden sich
alle Elemente 3 nach Zeilen angeordnet, im Objekt der Klasse DSLUCol nach Spalten
geordnet, jedoch lediglich die Zeilenindizes (und nicht die numerischen Werte).
Diese Redundanz in den Datenstrukturen ermöglicht es, effizient auf die Elemente
der aktiven Submatrix zugreifen zu können. Zum Beispiel ist die L-loop stark spaltenorientiert,
während ein zeilenweiser Aufbau den Zugriff auf die Elemente in der
Pivotzeile innerhalb der Update-loop vereinfacht.
3.5.2 Elimination von Singletons
Als nächster Schritt gemäß Algorithmus 3.1 folgt die Elimination der row singletons.
Im ersten Iterationsschritt werden hierzu alle lokalen Zeilen betrachtet und aus
den gefundenen Singletons ein lokales Array gebildet, was dann mittels der gossip-
Methode zu einem globalen zusammengefügt wird. Hierbei stellte sich heraus, daß es
wichtig ist, Informationen über die Reihenfolge der Singletons innerhalb dieses Arrays
zu speichern. Erinnert man sich an die Gossip-Struktur (siehe Abbildung 3.2), so
bemerkt man, daß bei einem simplen Zusammenfügen (“concatenate”) der Daten jedes
PE zum Schluß eine andere Reihenfolge der Einzeldaten innerhalb der gesamten
Daten besitzt (angefangen mit den eigenen Daten). Würde man jetzt die so ermittelten
Pivots der Reihe nach eliminieren (d. h. die Permutation festhalten), so entstünde auf
2 Als eigene Betriebsmittel werden im folgenden solche bezeichnet, die zur Laufzeit lokal sind.
3 Element ist hier und im folgenden meist ein abstrakter Begriff, der noch nichts über die Information
aussagt, mittels derer das mathematische Objekt Element einer Matrix beschrieben wird.
32

3.5 Die Klasse DSLUFactor
jedem PE eine eigene Pivotreihenfolge, was an und für sich kein Problem darstellt.
Will man jedoch später in einem kooperativen Kontext auf die Permutationen zugreifen
(sprich bei einem parallelen Löser), so müssen diese global konsistent sein. Die
Reihenfolge spielt dabei keine Rolle (da alle Singletons kompatibel sind) 4 , sie muß
nur eindeutig sein. Die Singletons werden deshalb nach aufsteigender PE Nummer
eliminiert. Dazu wird die L-loop für den lokalen Teil der Pivotspalte durchgeführt
und die Ergebnisse dann ausgetauscht.
Alle sukzessiven Iterationsschritte werden nur anhand der Rowcounts vorgenommen,
die sich geändert haben, d. h. es werden nicht wieder alle Zeilen “angefaßt”,
sondern nur diejenigen, in denen sich eine Veränderung aufgrund der letzten Iteration
ergeben hat, die also neue Singletons enthalten können. Wie bereits angeklungen,
steht an jedem Ende der Iterationsschleife ein Austausch (mittels gossip) der Änderungen
(Updates) an den Rowcounts (Änderungen an den Columncounts können
sich nicht ergeben). Dies braucht jedoch nur in X-Richtung des Prozessorgitters zu
erfolgen, da nur die globalen Rowcounts für eigene Zeilen benötigt werden. Die Iterationsschleife
wird abgebrochen, falls keine Singletons mehr vorhanden sind. Der
vollständige Algorithmus zur Elimination der Row singletons ist in Algorithmus 3.2
angegeben.
repeat
Finde lokale Row singletons
Tausche Row singletons aus
for all Row singletons do
Führe lokalen Teil der L-loop aus
Tausche entstandenen Teil von ¯L aus
end for
Tausche Änderungen an den Rowcounts aus
until keine Row singletons mehr vorhanden
Algorithmus 3.2: Elimination von Row singletons
Anschließend werden die Column singletons eliminiert. Dies geschieht im Prinzip
analog zu Algorithmus 3.2, jedoch entfällt hier die Ausführung der L-loop sowie das
Austauschen der Elemente in ¯L. Da in den jeweiligen Zeilen der Column singletons
weitere Elemente vorhanden sein können, müssen die Pivotzeilen traversiert werden,
um die entsprechenden Änderungen an den Columncounts vornehmen zu können.
Diese werden wieder mittels gossip ausgetauscht und dann im nächsten Schritt zur
4 allenfalls für die Genauigkeit des Lösers, die von der Reihenfolge der mathematischen Operationen
auf den Fließkommarepräsentationen der Elemente abhängt. Eine Optimierung in dieser Hinsicht
ist hier aber nicht angestrebt.
33

3 Parallele LR-Zerlegung
Ermittlung neu entstandener Column singletons eingesetzt. Der Algorithmus zur Eliminierung
von Column singletons ist in Algorithmus 3.3 angegeben.
repeat
Finde lokale Column singletons
Tausche Column singletons aus
for all Column singletons do
Traversiere Pivotzeile und etabliere lokale Änderungen der Columncounts
end for
Tausche Änderungen an den Columncounts aus
until keine Column singletons mehr vorhanden
Algorithmus 3.3: Elimination von Column singletons
3.5.3 Faktorisierung des Nukleus
Die verbleibende Submatrix nach Elimination von Singletons enthält nur noch Zeilen
und Spalten mit jeweils mehr als einem Nichtnullelement. Sie wird Nukleus der zu
faktorisierenden Matrix genannt. Es ist zwar möglich, daß während der Faktorisierung
des Nukleus weitere Singletons auftreten, jedoch ist deren Anzahl so gering, daß
eine gesonderte Behandlung derselben zu keiner Performancesteigerung führt. Solange
die Matrix dünnbesetzt ist, wird zur Faktorisierung in jedem Schritt eine Menge
kompatibler Pivotelemente ausgewählt. Anschließend führt jedes PE die L-loop
über lokale Elemente aus. Die daraus entstehenden Segmente 5 von ¯L (die Elemente
¯l i js von ¯L in der Pivotspalte j s mit i ≠ i s ) werden ebenso wie die lokalen Segmente
der Pivotzeilen (die Elemente a is j in der Pivotzeile i s mit j ≠ j s ) ausgetauscht. Danach
wird die Update-loop parallel ausgeführt. Dadurch ergeben sich Änderungen an
den Rowcounts sowie Columncounts durch Fill-in, Elimination der Pivotmenge sowie
evtl. durch Auslöschung von Elementen innerhalb der Update-loop (sehr selten ist
a (s)
i j = ¯l i js ⋅ a (s)
i s j ⇒a(s+1) i j = 0). Außerdem können sich die Maximalbeträge der Elemente
in den Zeilen ändern. Diese Änderungen werden nach Durchführung der Update-loop
mittels Gossip ausgetauscht, so daß die Daten für die Ermittlung der Pivotmenge im
nächsten Eliminationsschritt lokal zur Verfügung stehen. Algorithmus 3.4 zeigt die
parallele Faktorisierung des Nukleus.
5 Ein Segment definiere hier eine Menge von Elementen eines Vektors.
34

3.5 Die Klasse DSLUFactor
while Dimension der aktiven Submatrix > 0 do
if aktive Submatrix dünnbesetzt? then
Wähle Menge kompatibler Pivots
else
{aktive Submatrix dichtbesetzt}
Wähle Pivot
end if
for all Pivots do
Führe lokalen Teil der L-loop aus
Tausche neue Segmente von ¯L und Pivotzeile aus
end for
for all Pivots do
Führe lokalen Teil der Update-loop aus
end for
Tausche Änderungen der Rowcounts aus
Tausche Änderungen der Columncounts aus
Tausche Änderungen der Maximalelemente aus
end while
Algorithmus 3.4: Faktorisierung des Nukleus
Auswahl der Pivotmenge
Die Auswahl einer geeigneten Menge von Pivotelementen, die in einem parallelen
Schritt eliminiert werden, unterliegt einer Reihe von Forderungen:
• Vermeidung von Fill (siehe Seite 12)
• Numerische Stabilität (siehe Seite 14)
• Große Menge von kompatiblen Pivots
• Gleichmäßige Lastverteilung auf die einzelnen PEs
Wie man die ersten beiden Forderungen möglichst gut erfüllt, wurde bereits im letzten
Kapitel behandelt. Hier tauchen aber zwei weitere Forderungen auf, die es zu erfüllen
gilt, und die in Einklang mit den anderen beiden gebracht werden müssen. Wiederum
läßt sich auch bei diesem Problem keine optimale Lösung mit geringem Aufwand
finden, so daß man erneut auf eine heuristische Herangehensweise angewiesen ist.
Glücklicherweise widerspricht die Forderung nach einer großen Menge von Pivots
nicht den anderen Erfordernissen. Vielmehr sieht es statistisch so aus, als wenn
die Forderung nach Vermeidung von Fill sogar die Bildung einer großen Menge von
35

3 Parallele LR-Zerlegung
kompatiblen Pivots begünstigt. Schließlich ist es nach (3.1) wahrscheinlich, daß Elemente,
die eine geringe Anzahl von Nichtnullelementen in ihrer Zeile bzw. Spalte
haben, kompatibel zu vielen anderen Elementen sind.
Andererseits muß die Menge der kompatiblen Pivots auch, wie in 3.4.4 beschrieben,
auf ein “kleines” Maß beschränkt werden, so daß der Fill-in nicht überhandnimmt.
Denn orientiert man sich nur an der Größe der Pivotmenge, so kann es sein,
daß Elemente mit vergleichsweise schlechter Markowitz-Zahl ausgewählt werden,
weil diese zufällig zu solchen mit sehr guter Markowitz-Zahl kompatibel sind.
Darüberhinaus ist es wichtig, darauf zu achten, daß nicht ein starkes Ungleichgewicht
bei der Auswahl der Pivots entsteht, also z. B. Pivots fast ausschließlich von
einem PE ausgewählt werden. Dadurch würde nämlich die durch die Grid distribution
bezweckte Gleichverteilung der aktiven Submatrix unterlaufen werden, weil sich
auf einem PE die lokale Submatrix durch die Elimination der Pivotzeilen und -spalten
stark verringern würde im Vergleich zu anderen PEs.
Bisherige Ansätze Smart und White [19] setzen einen Algorithmus ein, in dem
die Pivotmenge S kompatible Elemente mit einer Markowitz-Zahl von mincount bis
mincount + a hat, wobei a ein Programmparameter ist. mincount ist die geringste
gefundene Markowitz-Zahl der aktiven Submatrix. Die Menge S wird, ausgehend
von der leeren Menge, sukzessive um Elemente mit aufsteigender Markowitz-Zahl
erweitert.
Der Algorithmus von Alaghband [1] generiert eine Anzahl von Mengen kompatibler
Pivots, von denen die größte Menge ausgewählt wird. Bei gleichgroßen Mengen
entscheidet die minimale Markowitzsumme. Aus der Pivotmenge S werden anschließend
Elemente entfernt, die eine Markowitz-Zahl haben, die größer als eine benutzerspezifizierte
Zahl ist oder deren Betrag kleiner als ein Thresholdparameter ist. Hier
wird also eine möglichst große Anzahl von Pivots angestrebt (u. U. zu Lasten des
Fill-in).
Der von Davis und Yew [6] vorgestellte Algorithmus generiert eine Pivotmenge S,
die Elemente mit einer Markowitz-Zahl von mincount bis a ⋅ mincount enthält, wobei
a ein Programmparameter ist (“typically two to eight”, a = 4 in ihren Experimenten).
Alle Prozessoren suchen nach akzeptablen Pivotkandidaten und versuchen, sie
zu der momentanen Menge S hinzuzufügen. Falls ein Kandidat kompatibel mit allen
Elementen von S ist, wird er hinzugefügt. Konflikte zwischen Prozessoren, die versuchen,
gleichzeitig einen Kandidaten hinzuzufügen, werden durch kritische Abschnitte
verhindert. Dies impliziert, daß der Algorithmus nichtdeterministisch arbeitet, da
Laufzeiten Einfluß auf das Ergebnis haben.
Van der Stappen, Bisseling und Van de Vorst [21] präsentieren einen Algo-
36

3.5 Die Klasse DSLUFactor
rithmus, der eine Menge S von Pivotkandidaten aufbaut, indem jeder Prozessor in
den ncol dünnbesetztesten Spalten nach akzeptablen Pivotkandidaten mit minimaler
Markowitz-Zahl sucht. Diese werden zusammengefügt, so daß jeder Prozessor
die globale Menge S von ncol Elementen hat, die aus den akzeptablen Elementen
mit den niedrigsten Markowitz-Zahlen besteht. Dabei wird S nach aufsteigenden
Markowitz-Zahlen sortiert. Anschließend werden Elemente mit einer unakzeptabel
hohen Markowitz-Zahl M i j > a ⋅ mincount entfernt. Die endgültige Menge S
wird dann, analog zu [19] sukzessive aus den Elementen gebildet, die die geringste
Markowitz-Zahl haben und zu den restlichen Elementen in S kompatibel sind.
Ein ähnlicher Algorithmus wird auch von Asenjo und Zapata [2] eingesetzt, jedoch
wird eine Abschwächung des Kompatibilitätskriteriums zugelassen, was zu einer
größeren Pivotmenge, aber auch zu einer aufwendigeren Update-loop führt.
All diesen Algorithmen ist gemein, daß sie bei der Pivotauswahl die obige letzte
Forderung nach Lastausgleich außer acht lassen. Dies wird vielmehr durch den Permutationsschritt
geleistet. Zeilen und Spalten der Matrix A können implizit (durch
Gebrauch der Permutationsvektoren π und ρ wie in Algorithmus 2.1) oder explizit
(durch Verschieben der Daten innerhalb der Matrix) permutiert werden. Explizite
Permutation führt zu einer guten Lastverteilung (Prozessoren, die Nichtnullelemente
durch Elimination verlieren, bekommen durch explizite Permutation neue Elemente
zugewiesen, was zu einem Lastausgleich führt). Die Lastverteilung bei impliziter
Permutation hängt jedoch von der “zufälligen” Pivotreihenfolge ab. Aus diesem
Grund implementieren die meisten parallelen LR-Zerlegungs-Algorithmen eine explizite
Permutation.
Auswahlalgorithmus in DSLUFactor Die Auswahl der Pivotmenge in dieser Arbeit
orientiert sich weitgehend an [23]. Die Auswahl geschieht dabei in drei Phasen.
In Phase A wird zunächst eine lokale Liste 6 von Pivotkandidaten aufgestellt, die dann
zu einer globalen, sortierten Liste zusammengefügt wird, aus der Elemente mit inakzeptabel
hoher Markowitz-Zahl entfernt werden. In Phase B werden Inkompatibilitäten
erfaßt und in Phase C die Menge S durch sukzessives Hinzufügen (bzw. Entfernen
der inkompatiblen Elemente) von Elementen mit niedriger Markowitz-Zahl gebildet.
Phase A: Lokale Auswahl von Pivotkandidaten Algorithmus 3.5 zeigt den hier
eingesetzten Algorithmus zur Auswahl einer Menge von lokalen Pivotkandidaten.
Jedes PE wählt also c p (oder weniger, falls nicht mehr c p Elemente auf dem lokalen
PE vorhanden sind) Pivotkandidaten aus. Die Auswahl selber geschieht da-
6 Im folgenden wird stets von einer Liste gesprochen, die streng genommen eine Menge ist, intern
aber als DataArray repräsentiert ist.
37

3 Parallele LR-Zerlegung
for m = 1 to c p do
Wähle lokalen Pivotkandidaten a i j
Füge a i j in lokale sortierte Liste von Pivotkandidaten ein
end for
Bilde globale sortierte Liste von Pivotkandidaten mittels gossip
for all Pivotkandidaten a i j do
if M i j > a ⋅ M i0 j 0
then
Entferne a i j aus der globalen Liste von Pivotkandidaten
end if
end for
Algorithmus 3.5: Lokale Auswahl von Pivotkandidaten
bei mittels Algorithmus 2.2. Betrachtet man noch einmal Algorithmus 2.2, so sieht
man, daß zu Beginn jeden Durchlaufs der repeat-Schleife die Bestimmung der Zeile
oder Spalte mit der geringsten Anzahl von Nichtnullelementen (d. h. des geringsten
Rowcounts bzw. Columncounts) steht. Dies soll natürlich nicht durch wiederholtes
Durchsuchen aller Zeilen und Spalten geschehen. Deshalb hat jedes DSLURow- bzw.
DSLUCol-Objekt ein Array von Objekten der Klasse IdRing, die ebenfalls im Rahmen
dieser Arbeit entstand. Die Klasse IdRing implementiert einen doppelt verketteten
Ring, der hier dazu dient, die Indizes der Zeilen bzw. Spalten mit gleichem Rowbzw.
Columncount zu speichern. Das Array faßt die Ringe nach aufsteigender Nichtnullelementeanzahl
zusammen, so daß man mittels min[c] auf den Ring von Indizes
mit einer Nichtnullelementeanzahl von c+1 7 zugreifen kann. Die Arrayelemente sind
dabei Dummies, die nur als Anfangspunkte der Ringe dienen. Die Ringelemente sind
in einem weiteren Array gespeichert, das einen direkten Zugriff über die Zeilen- bzw.
Spaltennummer erlaubt und so das Umhängen von Indizes vereinfacht. Ein Ring ist
also leer, wenn das erste Element des Rings sich selbst als Nachfolger sowie Vorgänger
hat. Abbildung 3.4 zeigt ein Beispiel eines Rings. Die Zeile (oder Spalte) 11 hat
hier 48 Nichtnullelemente. Sie ist dazu in den Ring mit Index 47 eingehängt. Weiterhin
kann man auf das Ringelement anhand des oberen Arrays zugreifen. 8 Es gibt
keine Zeile (oder Spalte) mit 49 Nichtnullelementen, deshalb ist der Ring 48 leer.
Auf diese Art und Weise kann also schnell auf die Zeile oder Spalte mit der geringsten
Anzahl von Nichtnullelementen zugegriffen werden. Das Überprüfen der
Threshold-Bedingung (2.16) geschieht anhand eines Arrays des DSLURow-Objektes,
das die Maximalbeträge der Zeilen des eigenen PEs gespeichert hat. Änderungen
7 Arrays sind von 0 bis n−1 durchnumeriert und eine Zeile oder Spalte kann 1 bis n Nichtnullelemente
enthalten.
8 Die beiden Kästchen mit der Zahl 11 symbolisieren hier natürlich dieselbe Speicherstelle.
38

10
46
3.5 Die Klasse DSLUFactor
11 12
47 48
11
Abbildung 3.4: Beispiel der Ring-Struktur
hieran werden ebenso wie Änderungen an den Row- und Columncounts (anhand derer
auch die Ringe aktualisiert werden) nach jedem Eliminationsschritt ausgetauscht.
Beim Durchsuchen von Spalten muß zur Überprüfung des Threshold-Kriteriums der
Wert des potentiellen Pivotkandidaten erst in der zugehörigen Zeile gesucht werden,
was für Matrizen mit sehr vielen Elementen zum dominierenden Zeitfaktor werden
kann – deshalb kann die Suche mittels eines Programmparameters auf Zeilen beschränkt
werden. 9 Die entsprechende Zeile von Algorithmus 2.2 lautet dann:
Wähle i ∈ I′ mit minimaler Anzahl von Nichtnullelementen
Nachdem ein lokaler Pivotkandidat best gefunden wurde, wird dessen Zeilen- sowie
Spaltenindex aus den jeweiligen Ringen ausgehängt, damit die Zeile und Spalte im
nächsten Schritt der lokalen Pivotauswahl nicht noch einmal durchsucht wird.
Als nächstes wird der Pivotkandidat in die lokale sortierte Liste von Pivotkandidaten
eingefügt. Dies geschieht mittels Insertion Sort anhand der Ordnungsrelation
a i j ˙≤ a kl ⇔
M i j < M kl oder
(M i j = M kl und i < k).
(3.7)
9 In Experimenten führte dies zu einer nur geringfügigen Verschlechterung der Pivotreihenfolge.
39

3 Parallele LR-Zerlegung
˙≤ ist eine totale Ordnung für die Menge der lokalen Pivotkandidaten, da i ≠ k für alle
Pivotkandidatenpaare (a i j ,a kl ).
Besondere Aufmerksamkeit verdient der Parameter c p , der die (maximale) Anzahl
der im aktuellen Pivotschritt von einem PE auszuwählenden Pivotkandidaten festlegt.
Wie bereits oben erwähnt, implementieren die meisten LR-Zerlegungs-Algorithmen
eine explizite Permutation, die ein dynamisches Load-balancing verwirklicht. Dies ist
notwendig, da die statische Lastverteilung mittels der Grid distribution sich während
der Laufzeit stark verändern kann. Nachteil bei expliziter Permutation ist der stark erhöhte
Kommunikationsaufwand. Deshalb wird im Algorithmus von DSLUFactor der
Parameter c p zum dynamischen Lastausgleich genutzt. Dieses Verfahren ist erstmals
in [23] beschrieben und wird hier modifiziert eingesetzt. Ziel des Verfahrens ist es,
daß höherbelastete PEs auch mehr lokale Pivotkandidaten auswählen, damit sie durch
Elimination derselben stärker an Last (d. h. an Nichtnullelementen in den Pivotzeilen
und -spalten) verlieren als wenigerbelastete PEs, und sich so ein Lastausgleich ergibt.
Der Aufwand des Algorithmus zur Pivotauswahl ist wesentlich geringer als der der
Update-loop, so daß die Erhöhung des ersteren kaum ins Gewicht fällt im Vergleich
zum Ausgleich des letzteren.
Ein Maß für die Belastung eines PEs ist die Größe des lokalen Anteils an der
aktiven Submatrix
d p = |I | ⋅ | J|,
d. h. d p ist das Produkt der Anzahl der lokalen Zeilen und der Anzahl der lokalen
Spalten. Es wäre auch möglich, das Besetzungsmuster der aktiven Submatrix als
Maß für die Belastung heranzuziehen, was noch akkurater wäre. Dies würde jedoch
zusätzlichen Rechenaufwand bedeuten, weshalb hier der einfachere Ansatz gewählt
wurde. 10 Jedes PE wählt in Schritt s eine Anzahl von lokalen Pivotkandidaten
c p = d p
n 2 c, (3.8)
s
wobei n s die Dimension der aktiven Submatrix ist und c ein Programmparameter. In
[23] wird gezeigt, daß die optimale Größe von c nur von der Prozessorgeschwindigkeit
sowie von Latenzzeiten bei der Kommunikation abhängt, nicht jedoch von der zu
faktorisierenden Matrix. Im nächsten Kapitel wird das Thema Load-balancing noch
einmal aufgegriffen.
Hat jedes PE c p lokale Pivotkandidaten ausgewählt, so werden diese mittels
gossip zu einer globalen Liste von Pivotkandidaten zusammengefügt. Dies geschieht
10 In [23] wird nur die Anzahl der Zeilen verwendet, da dort eine zeilenweise Verteilung der Matrix
zugrunde gelegt wurde.
40

3.5 Die Klasse DSLUFactor
dermaßen, daß die GossipFunction in jedem Kommunikationsschritt die lokale und
entfernte Liste von Pivotkandidaten mittels Merge Sort zu einer global sortierten verschmilzt.
Hierbei kann es aber vorkommen, daß Pivotkandidaten sowohl die gleiche
Markowitz-Zahl als auch die gleiche Zeilennummer haben, weshalb erst die Ordnungsrelation
a i j ˙≤ a kl ⇔
M i j < M kl oder
(M i j = M kl und i < k) oder
(M i j = M kl und i = k und j < l)
(3.9)
eine totale Ordnung über der Menge der globalen Pivotkandidaten definiert. Nach
dem gossip-Schritt hat jedes PE dieselbe globale Liste von Pivotkandidaten.
Aus dieser werden im letzten Schritt der Phase A noch die Elemente entfernt, die
eine unakzeptabel hohe Markowitz-Zahl aufweisen.
Phase B: Erkennung von Inkompatibilitäten In Algorithmus 3.6 wird der Ablauf
der zweiten Phase des in DSLUFactor verwendeten Algorithmus zur Pivotauswahl
gezeigt.
for all Pivotzeilen i (von Pivotkandidaten a i j ) do
for all lokale Elemente a il do
if Pivotkandidat a kl ≠ a i j in Spalte l then
if a i j ˙≤ a kl then
Füge (a i j ,a kl ) zur Liste von Inkompatiblen hinzu
else
Füge (a kl ,a i j ) zur Liste von Inkompatiblen hinzu
end if
end if
end for
end for
Bilde globale Liste von Inkompatiblen mittels gossip
Algorithmus 3.6: Erkennung von Inkompatibilitäten
Ziel der Phase B ist es, alle Inkompatibilitäten zwischen Elementen der globalen
Liste der Pivotkandidaten zu erkennen. Dies soll so geschehen, daß am Ende dieser
Phase die Relation N ⊆ S × S auf allen PEs vorhanden ist, wobei S die Menge der
41

3 Parallele LR-Zerlegung
globalen Pivotkandidaten symbolisiert und die zweistellige Relation N definiert ist
als
(a i j ,a kl ) ∈ N ⇔
(a il ≠ 0 oder a k j ≠ 0) und
a i j ˙≤ a kl .
(3.10)
N wird als DataArray von Strukturen der Form
struct Incomp
{
short a,b;
Incomp(int x=-1, int y=-1): a(x), b(y) {};
};
repräsentiert, d. h. jedes Incomp-Objekt definiert ein geordnetes Paar (a,b). Dies
ermöglicht eine geringe Kommunikationskomplexität beim anschließenden Gossip,
kann jedoch redundanter als eine Repräsentation als |S | ⋅ | S|-Array sein (oder anderer
Datenstrukturen), jedoch nur bei sehr vielen Inkompatibilitäten, d. h. dem Vorliegen
einer sehr dichtbesetzten Submatrix, wovon hier aber nicht ausgegangen wird, da dieser
Fall gesondert behandelt wird (siehe Algorithmus 3.4).
Betrachtet man noch einmal (3.1), so würde ein naiver Ansatz zur Bildung der
Relation N vielleicht lauten, für ein Element a i j der globalen Liste von Pivotkandidaten
alle anderen Pivotkandidaten a kl durchzugehen und zu untersuchen, ob es ein
Nichtnullelement a il gibt, das auf eine Inkompatibilität hindeutet und dann das Paar
(a i j ,a kl ) (bzw. (a kl ,a i j )) der Relation N hinzuzufügen. 11 Dieses Vorgehen hätte einen
Aufwand vonO (|S| 2 ). Dies bedeutet aber einen unnötigen Aufwand bei der mehrfachen
Suche in Zeilen des Pivotkandidaten a i j .
Deshalb wird bei der Feststellung von Inkompatibilitäten der umgekehrte Weg
gegangen, d. h. es werden alle Zeilen von Pivotkandidaten nach Nichtnullelementen
untersucht, die zwei Pivotkandidaten inkompatibel zueinander machen. Jedes PE geht
also alle (lokalen Teile der) Zeilen durch, in denen ein Pivotkandidat a i j vorhanden
ist und prüft dabei für jedes Nichtnullelement a il , ob es zu einer Inkompatibilität zu
einem anderen Pivotkandidaten führt, d. h. ob in der betreffenden Spalte l ein Pivotkandidat
a kl existiert. Hierzu ist natürlich eine Datenstruktur notwendig, die diese
Überprüfung inO (1) ermöglicht. Deshalb wird noch ein DataArray angelegt, das für
jede Spalte Auskunft gibt, ob in ihr ein Pivotkandidat vorhanden ist. Dadurch ergibt
42

3.5 Die Klasse DSLUFactor
S
0 1 2
a gh a i j
a kl
1 ⊥ 0 2
a i j a im 0 a il
a kl
a gh
Abbildung 3.5: Erkennung von Inkompatibilitäten
sich für Algorithmus 3.6 ein Aufwand vonO (|S|). Abbildung 3.5 zeigt noch einmal
alle relevanten Elemente der Phase B.
In diesem Beispiel besteht die globale Liste der Pivotkandidaten S aus drei Elementen
a gh ˙≤ a i j ˙≤ a kl . Beim Untersuchen der Zeile i wird eine Inkompatibilität zwischen
a i j und a kl (dem Pivotkandidaten mit dem Index 2 in S) aufgrund von a il festgestellt.
In Spalte m befindet sich kein Pivotkandidat (durch ⊥ angedeutet), deshalb
entsteht aufgrund von a im keine Inkompatibilität. Es besteht ebenfalls keine Inkompatibilität
zwischen a i j und a gh , da a ih = 0. 12 Nach der Untersuchung von Zeile i ist
N also um (a i j ,a kl ) erweitert.
Abschließend werden alle Teilrelationen mittels gossip zu einer großen Relation
vereinigt. In jedem Gossip-Schritt werden also die kommunizierten DataArrays
zusammengefügt.
11 Äquivalent wäre es natürlich, nur alle größeren (im Sinne von ˙≤ ) Pivotkandidaten durchzugehen
und dann auch nach a k j zu suchen.
12 Es könnte eine Inkompatibilität durch a g j entstehen. Dies wird beim untersuchen von Zeile g geprüft.
43

3 Parallele LR-Zerlegung
Phase C: Auswahl kompatibler Pivotkandidaten Zu Beginn der Phase C verfügt
jedes PE über die gleiche globale Liste von Pivotkandidaten sowie über die gleiche
Menge von geordneten Paaren inkompatibler Elemente. Mittels dieser Informationen
soll nun in dieser Phase eine Menge von kompatiblen Pivotkandidaten erstellt werden,
die möglich (“feasible”) und optimal ist. Möglich ist eine Menge von Pivotkandidaten
S′⊆S genau dann wenn
feasible(S′) ⇔
∀(a i j ,a kl ) ∈ S′×S′: (a i j ,a kl ) ∉ N,
d. h. alle Pivotkandidaten kompatibel sind. Das Optimalitätskriterium wird als
optimal(S′) ⇔
∀Q ⊆ S, feasible(Q): |Q| ≤ |S′| und
∀Q ⊆ S, feasible(Q), |Q| = |S′|: ∑M i j ≤ ∑M kl , a i j ∈ S′, a kl ∈ Q
definiert, d. h. die Forderungen nach Minimierung der Summe der Markowitz-Zahlen
(die ein Maß für den potentiellen Fill-in angeben) sowie einer möglichst großen Pivotmenge
werden hier angestrebt.
Um zu einer optimalen Lösung zu gelangen, müssen Verfahren der globalen Optimierung
eingesetzt werden (“backtrack”, “branch and bound” o. ä.), da kein Kriterium
existiert, daß für jede partielle Lösung entscheidet, welcher Pivotkandidat hinzugenommen
werden muß, um zu einer optimalen Lösung zu gelangen. In DSLUFactor
wurde jedoch trotzdem ein lokaler Optimierungsalgorithmus (“greedy algorithm”)
eingesetzt, da es sich nicht lohnt, den Mehraufwand zur Auffindung einer optimalen
Lösung zu betreiben, die nur geringfügig besser ist als die heuristisch gewonnene.
Algorithmus 3.7 zeigt diesen Algorithmus.
m:= 1;
while m Elemente in der globalen Liste von Pivotkandidaten vorhanden do
{a i j ist m-tes Element der globalen Liste von Pivotkandidaten}
for all geordneten Paare (a i j ,a kl ) aus der globalen Liste von Inkompatiblen do
Entferne a kl aus der globalen Liste von Pivotkandidaten
end for
m:= m + 1;
end while
Algorithmus 3.7: Phase C: Auswahl kompatibler Pivotkandidaten
Das heuristische Auswahlkriterium lautet also, immer das Element mit der kleinsten
Markowitz-Zahl (also das vorderste in der sortierten Liste) auszuwählen und alle
44

3.5 Die Klasse DSLUFactor
dazu inkompatiblen zu entfernen usf. Hierbei wird natürlich die Forderung nach einer
möglichst großen Pivotmenge außer acht gelassen, was aber hoffentlich durch die
geringen Markowitz-Zahlen der ausgewählten Elemente dennoch zum Tragen kommt.
Die in Phase B aufgestellte Relation N als Array von Incomp-Objekten eignet
sich schlecht für die Durchführung von Algorithmus 3.7, da man auf alle Inkompatiblen
eines Pivotkandidaten hintereinander zugreifen will. Deshalb wird zu Beginn
der Phase C in DSLUFactor noch eine Umformung von N vorgenommen, so daß die
Inkompatibilitäten in m DataArrays gespeichert werden, wenn m die Anzahl der Pivotkandidaten
ist.
Beim Durchführen des Algorithmus muß man weiterhin auf die Kohärenz der in
Phase A benötigten Ringe achten, d. h. alle Zeilen und Spalten der ausgewählten Pivotkandidaten
werden noch einmal aus ihren Ringen ausgehängt, da sie von einem
anderen PE ausgewählt sein können, also noch nicht in Phase A ausgehängt wurden.
Außerdem müssen die Zeilen und Spalten der Pivotkandidaten, die aus der Pivotmenge
entfernt werden, wieder in ihre Ringe eingehängt werden, da sie nicht eliminiert
werden und im nächsten Schritt wieder zur Auswahl herangezogen werden können.
Resümee Führt man sich noch einmal die Forderungen zu Beginn dieses Abschnittes
vor Augen, so sieht man, daß die in DSLUFactor implementierte Auswahl von Pivotelementen
jede der Zielsetzungen konsequent verfolgt. Die numerische Stabilität
wird durch das threshold pivoting in Phase A angestrebt. Die Minimierung des Fill-in
wird durch die Suche in den dünnbesetztesten Zeilen bzw. Spalten in Phase A effizient
umgesetzt, und durch die Bevorzugung von Kandidaten mit geringer Markowitz-Zahl
bei der Mengenbildung in Phase C weiter unterstützt. Darüberhinaus verhindert die
Markowitz-Zahlenbegrenzung nach [6], daß Ausreißer in die Pivotmenge aufgenommen
werden. Eine große Pivotmenge wird implizit durch die Auswahl von c p lokalen
Pivotkandidaten und die geringen Markowitz-Zahlen angestrebt. Dies könnte noch
intensiver betrieben werden, etwa durch globale Optimierungsverfahren in Phase C
oder eine lokale Optimierung, die Kandidaten mit wenig Inkompatiblen bevorzugt.
Eine gute Lastverteilung wird durch dynamisches, passives Load-balancing versucht
zu erreichen.
Die L-loop
Nach Beendigung der Pivotauswahl verfügt jedes PE über die globale Menge von
kompatiblen Pivots, die nach aufsteigender Markowitz-Zahl sortiert ist. Diese Menge
kann natürlich auch leer sein, d. h. es wurden keine Pivots gefunden. Das bedeutet
aber, daß es mindestens eine Zeile des Gleichungssystems Ax = b gibt, in der kein x i
auftaucht, es also keine eindeutig bestimmte Lösung des Gleichungssystems gibt. In
45

3 Parallele LR-Zerlegung
diesem Falle wird die Faktorisierung abgebrochen und der Wert −1 zurückgeliefert,
der die Singularität der Matrix anzeigt.
Betrachtet man noch einmal Algorithmus 3.4 sowie Algorithmus 2.1, so folgt als
nächster Schritt der Faktorisierung die Durchführung der L-loop, d. h. das Aufbauen
(eines Teils) der Matrix ¯L. Hierzu zunächst einige (evtl. trivial erscheinende) Aspekte,
die dabei Beachtung verdienen.
Vergegenwärtigt man sich noch einmal die Struktur der Matrix ¯L bzw. L wie in
Kapitel 2 beschrieben, so erkennt man, daß die Diagonalelemente l ii alle den Wert 1
haben. Diese Elemente werden natürlich nicht explizit behandelt und auch nicht in
Datenstrukturen gespeichert.
Teil der Aufgabenstellung ist es außerdem, daß die kompletten Matrizen L und R
nach Beendigung der Faktorisierung auf allen PEs vorhanden sind. Dies ermöglicht
die einfache Neuverteilung der Faktoren im anschließenden Lösungsschritt.
Bestandteil der L-loop ist hier auch der Austausch der Elemente in den Pivotzeilen,
die in der Update-loop benötigt werden. Die L-loop hat deshalb eine Doppelfunktion
– sie beinhaltet den Aufbau von ¯L sowie die den Austausch von Elementen,
die in der Update-loop benötigt werden.
Um eine geringe Komplexität der L-loop zu erreichen, ist es von Vorteil, hier nur
die unbedingt notwendige Arbeit zu verrichten. Aus diesem Grund wird an dieser
Stelle ein wenig auf die Struktur der Update-loop vorgegriffen, deren Durchführung
die Abarbeitung der L-loop voraussetzt. Abbildung 3.6 zeigt einen Ausschnitt der
aktiven Submatrix einer Beispielmatrix.
Alle gezeigten Elemente sind mit der Nummer des PEs gekennzeichnet, auf das
sie verteilt sind (4 PEs bei einer Verteilung im 2 × 2 Gitter). Die dunkel unterlegten
Elemente sind Pivotelemente (die restlichen Elemente in der linken oberen Ecke sind
imaginäre, da sie aufgrund der Kompatibilität den Wert 0 haben müssen). Links unten
ist der Teil der Matrix, dessen Elemente zur Bildung von ¯L dienen, wovon drei
Elemente hervorgehoben sind. Rechts oben sind drei Elemente der Pivotzeilen hervorgehoben.
Das Element, das sich im Schnittpunkt dieser Elemente befindet, ist ein
potentielles Update-Element. Wie unschwer ersichtlich, kann ein Update (oder ein
Fill-in) für ein PE (im Beispiel 0) nur passieren, wenn ein Element der Pivotzeile in
einer dem PE mittels der Grid distribution zugeordneten Spalte steht und ein Element
der Pivotspalte (aus der sich ¯L konstituiert) in einer dem PE zugeordneten Zeile steht.
Es können sich also für PE 0 in diesem Beispiel keine Updates aus Elementen einer
Pivotzeile ergeben, die PE 1 oder 3 zugeordnet sind. Ebensowenig können Updates
aus Elementen der Pivotspalte verursacht werden, die PE 2 oder 3 zugeordnet sind.
Es bietet sich deshalb an, die Elemente der Pivotzeile nur spaltenweise, d. h. innerhalb
von DSLUCol, und die Elemente von ¯L nur zeilenweise, d. h. innerhalb von
DSLURow auszutauschen. Dies wurde auch zunächst so implementiert. Um dann die
46

3.5 Die Klasse DSLUFactor
0 1 0
2 3 2
0 1 0
0
2
0
DSLUCol
0 1 0 0
DSLURow
Abbildung 3.6: Möglichkeiten für Updates
vollständigen Matrizen L und R auf allen PEs zu haben, ist am Ende der Faktorisierung
aber noch ein Schritt nötig, in dem die Elemente von ¯L und Ā 13 in der jeweils
anderen Richtung kommuniziert werden, d. h. die Elemente von ¯L zwischen den Zeilen
ausgetauscht werden und die Elemente von Ā zwischen den Spalten. In diesem
letzten Schritt wird also ein sehr hohes Datenvolumen transportiert, was zu “Verklemmungen”
des Verbindungsnetzwerks des T3D führt. Dies ergab einen so hohen Aufwand,
daß darunter die Gesamtperformance der Faktorisierung litt. Deshalb wurde
eine andere Kommunikationsstrategie innerhalb der L-loop verfolgt.
Es werden doch alle Elemente der Pivotzeilen und von ¯L innerhalb der L-loop
kommuniziert. Dies könnte natürlich mittels gossip geschehen, da diese Methode
eine geringe Kommunikationskomplexität und niedrige Latenzzeiten (wenige, aber
große Pakete) aufweist. Andererseits ist sie aber stark synchron, da immer auf das
Eintreffen von Daten spezifischer Partner in jedem Kommunikationsschritt gewartet
werden muß. Sie eignet sich also vornehmlich für Aufgaben, bei denen die Daten
noch reduziert werden müssen (z. B. Summenbildung oder das Merge Sort bei der
Pivotauswahl). In diesem Kontext (purer Datenaustausch) sollte aber ein asynchroneres
Verfahren eingesetzt werden. Dazu dient die Klasse MVector, die ebenfalls im
13 Ā ist nach Beendigung der Faktorisierung die nichtpermutierte R-Matrix.
47

3 Parallele LR-Zerlegung
Rahmen dieser Arbeit entstand.
Die Klasse MVector Die Klasse MVector (“Vektor von Matrixelementen”) stellt
eine komplette Unterstützung für die verteilte Speicherung von dünnbesetzten Matrizen
zur Verfügung. Sie ist eine abgeleitete Klasse von DSVector (“dynamic sparse
vector”) [22] und übernimmt so die Funktionalität der Speicherung eines dünnbesetzten
Vektors. Dieser Vektor ist aber unterteilt in Untervektoren, die dynamisch
erzeugt werden können und so eine Sicht auf verschiedene Zeilen oder Spalten bietet.
Weiterhin wird die Unterscheidung in lokale und globale Anteile der Untervektoren
eingeführt, sowie Kommunikationsmethoden zum Austausch der jeweiligen Anteile.
Ein Untervektor eines MVectors kann nicht vergrößert werden, so daß dessen jeweilige
Größe im voraus bekannt sein muß, d. h. bevor die Elemente hinzugefügt werden.
Die Anzahl der Untervektoren ist jedoch dynamisch, so daß sukzessive neue Vektoren
hinzugefügt werden können. Dieses Konzept vermeidet häufige realloc()s
und das Umkopieren von Vektoren. Der typische Benutzungszyklus eines MVectors
sieht etwa so aus:
1. Festlegen der maximalen Zahl von Untervektoren (die Dimension der durch den
MVector beschriebenen Matrix)
2. Kreieren einer Anzahl von neuen Untervektoren (mit vorgegebener Größe)
3. Hinzufügen von lokalen Elementen zu diesen Untervektoren
4. Konstruieren der globalen Untervektoren (kommunizieren mit anderen PEs)
5. Wiederholen der Schritte 2-4
6. Benutzen der Untervektoren
Abbildung 3.7 zeigt den Aufbau eines MVectors. In diesem Beispiel wurden zwei
Untervektoren (0 und 1) kreiert, die die Zeilen 17 bzw. 29 repräsentieren. Die unterlegten
Bereiche symbolisieren den Füllstand der Zeilen, d. h. in Zeile 17 wurden
schon alle lokalen sowie globalen Elemente eingefügt, in Zeile 29 fehlen noch einige
lokale Elemente und es sind noch nicht alle entfernten Elemente von den anderen PEs
eingetroffen. Der restliche Bereich des MVectors ist noch frei, d. h. hier können noch
Untervektoren kreiert werden, ohne daß ein realloc() fällig wird.
Besondere Bedeutung kommt der Kommunikationsmethode
void MVector::broadcast(int c);
48

3.5 Die Klasse DSLUFactor
0 1 2
lokaler Teil von
Zeile 17
globaler Teil von
Zeile 17
lokaler Teil von
Zeile 29
globaler Teil von
Zeile 29
Abbildung 3.7: Aufbau eines MVectors
Freier Teil des
MVectors
zu, deren Name schon verrät, daß sie Informationen an alle anderen PEs verschickt.
Der Parameter c bezeichnet den Untervektor, dessen lokaler Anteil auf die anderen
PEs verteilt werden soll. Die Funktionalität der Methode ist es, den lokalen Teil des
Untervektors c (in Abbildung 3.7 hell unterlegt) in den globalen Bereich des Untervektors
c (in Abbildung 3.7 dunkel unterlegt) auf allen anderen PEs zu schreiben.
Nachdem alle PEs ein broadcast(c) ausgeführt haben, sollen alle PEs den gleichen
Untervektor zur Verfügung haben, wobei die Reihenfolge der Elemente keine Rolle
spielt. Es muß also eine Regelung gefunden werden, wohin ein Prozessor seine Daten
schreibt, ohne Daten von anderen PEs zu überschreiben, da lediglich die Größe und
die Anfangsadresse des globalen Bereichs für jedes PE bekannt ist.
Ein Ansatz wäre es, auf jedem PE einen Füllstand des globalen Bereichs zu speichern,
dessen Veränderung nur innerhalb eines kritischen Abschnitts stattfinden kann,
und sich der globale Bereich somit schrittweise füllt, wenn die PEs ihre Daten hineinschreiben.
Dies bedeutet jedoch, daß die Kommunikation synchronisiert ist, d. h.
es kann Overhead entstehen, während ein PE auf die Freigabe des kritischen Bereichs
wartet. Oben wurde jedoch bereits erwähnt, daß Synchronität prinzipiell “böse” ist,
besonders bei einer Broadcast-Methode, die viele Einzelschritte braucht im Gegensatz
zu einer kollektiven Methode wie dem Gossip.
Die in MVector eingesetzte Methode kommt daher völlig ohne Synchronisation
aus. Zur Übertragung der Daten wird shmem_put eingesetzt. Abbildung 3.8 veranschaulicht
das Vorgehen anhand eines Beispiels. Es ist dabei ein Untervektor dargestellt,
der auf vier PEs verteilt ist, von denen drei gezeigt sind. Im oberen Teil ist
der erste Schritt des Broadcast von PE 0 skizziert, im unteren Teil der zweite (von
insgesamt drei). Die hell unterlegten Bereiche sind wieder die lokalen Anteile der
Untervektoren, die dunkel unterlegten bereits eingetroffene Teile des globalen An-
49

3 Parallele LR-Zerlegung
1)
0 3 2 1 1 0 3 2 2
1 0 3
2)
0 3 2 1 1 0 3 2 2 1 0 3
Abbildung 3.8: Ablauf von MVector::broadcast
teils. Nicht unterlegte Bereiche stellen noch nicht eingetroffene Teile des globalen
Anteils dar, es sind sozusagen die Slots für die entfernten PEs, in die ihre Daten hineingeschrieben
werden. 14
Das Vorgehen ist also folgendermaßen. PE 0 schreibt zuerst seine Daten an den
Anfang des globalen Bereichs von PE 1 und liest die Größe des lokalen Bereichs von
PE 1 (mittels shmem_get). Dies ist durch die Pfeile angedeutet. Im zweiten Schritt
schreibt PE 0 seine Daten in den globalen Bereich von PE 2, läßt aber Platz für die
Daten von PE 1 (deren Größe es im vorherigen Schritt gelesen hat). Es liest weiterhin
die Größe des lokalen Bereichs von PE 2, die es zu der Größe des lokalen Bereichs
von PE 1 (dem Offset) addiert. In diesem Sinne wird weiter verfahren, bis alle PEs die
Daten von PE 0 haben. Für die anderen PEs ist das Vorgehen analog, sie fangen jedoch
immer beim jeweils folgenden PE im round-robin Sinne an, d. h. PE 3 würde im Beispiel
bei PE 0 beginnen usw. Die verschiedenen Aufrufe von MVector::broadcast
sind dabei völlig autark, d. h. die PEs müssen nichts von den Kommunikationsvorgängen
auf anderen PEs wissen. Der Kommunikationsalgorithmus ist noch einmal in
Algorithmus 3.8 angegeben.
Durchführung der L-loop Mittels MVectors kann die L-loop wesentlich vereinfacht
werden. Die Klasse DSLUFactor hat zwei MVectors uv und lv, die die Pivotzeilen
(d. h. die nichtpermutierte R-Matrix) bzw. die ¯L-Matrix aufnehmen.
Es wird also zunächst für jeden Pivot ein Untervektor in uv, der die Pivotzeile
repräsentiert, und ein Untervektor in lv, der die entsprechende Spalte von ¯L repräsentiert,
erzeugt.
14 Diese Slots sind nicht explizit vorhanden, da sie Kenntnis über die Größe der lokalen Anteile auf
anderen PEs voraussetzen, die zu Beginn des Broadcast nicht vorhanden ist.
50

3.5 Die Klasse DSLUFactor
offset:= 0;
pe:= (me + 1) mod p;
{me ist lokales PE, p Anzahl der PEs}
while pe ≠ me do
start:=Anfang des globalen Bereichs auf PE pe;
Schreibe lokale Daten an start+offset auf PE pe
offset:= offset+Größe des lokalen Bereichs auf PE pe;
pe:= (pe + 1) mod p;
end while
Algorithmus 3.8: Algorithmus von MVector::broadcast
Dann wird für jeden Pivot zunächst dessen Spalte j s durchlaufen und die Elemente
¯l i js = a i js=a is j s
(vgl. Algorithmus 2.1) dem Untervektor lv[j s ] hinzugefügt. Dabei
werden gleichzeitig die Elemente a i js aus den Zeilen und der Spalte der aktiven Submatrix
(d. h. den SVSets) entfernt. Die Position des Elementes a i js in seiner Zeile
muß dabei erst durch Suchen bestimmt werden, was sich aber nicht vermeiden läßt.
Als nächstes wird der fertige lokale Teil der Spalte von ¯L mittels Broadcast an die
anderen PEs verteilt.
Analog wird mit der Pivotzeile verfahren, bloß das diesmal beim Entfernen die
betreffende Spalte durchsucht werden muß. Man könnte zwar vermuten, daß das Entfernen
von Elementen nicht notwendig sei, da die pivotisierten Zeilen bzw. Spalten
nicht noch einmal gebraucht werden (sie werden ja eliminiert), aber durch die doppelte
Abspeicherung sind Elemente z. B. aus der Pivotspalte noch in nicht eliminierten
Zeilen zu finden.
Den vollständigen Algorithmus zur Durchführung der L-loop zeigt Algorithmus
3.9.
Die Update-loop
Nachdem die Pivotzeilen und die relevanten Teile der ¯L-Matrix ausgetauscht wurden,
kann als nächster Schritt in Algorithmus 2.1 die Update-loop in Angriff genommen
werden.
Die Update-loop ist bei weitem der zeitaufwendigste Teil der Faktorisierung, da
ihr AufwandO (n 2 s) beträgt, wenn n s wieder die Dimension der aktiven Submatrix
darstellt. Dies ist klar, da im Fall einer dichtbesetzten Matrix wirklich jedes Element
der aktiven Submatrix geändert wird. Aus diesem Grund verlangt die Update-loop
nach einem besonders effizienten Algorithmus, der viele Optimierungen ermöglicht,
die eine gute Parallelität erzielen.
Wie bereits des öfteren erwähnt, ist eine möglichst asynchrone Abarbeitung der
51

3 Parallele LR-Zerlegung
for all Pivots a is j s
do
Kreiere Untervektor für Spalte j s in lv
Kreiere Untervektor für Zeile i s in uv
end for
for all Pivots a is j s
do
for all Elemente a i js in Spalte j s mit i ≠ i s do
Füge ¯l i js = a i js=a is j s
lv[j s ] hinzu
Entferne a i js aus Spalte j s
Entferne a i js aus Zeile i
end for
Verteile lokalen Teil von lv[j s ] mittels Broadcast
for all Elemente a is j in Zeile i s do
Füge a is j uv[i s ] hinzu
Entferne a is j aus Zeile i s
Entferne a is j aus Spalte j
end for
Verteile lokalen Teil von uv[i s ] mittels Broadcast
end for
Algorithmus 3.9: Durchführung der L-loop
einzelnen Faktorisierungsschritte von größter Bedeutung für einen effizienten parallelen
Algorithmus. Dies läßt sich häufig durch Konzentration der lokalen Bearbeitung
am Anfang der Berechnung erreichen.
Die Ausgangssituation zu Beginn der Update-loop sieht so aus, daß alle lokalen
Teile der MVectors uv und lv aufgebaut sind und an alle anderen PEs verschickt.
Aufgrund der asynchronen Kommunikation der L-loop ist aber das Vorhandensein
sämtlicher globaler Teile von uv und lv nicht gesichert. Dies könnte man durch eine
explizite Synchronisation (z. B. mittels des Barrier-Mechanismus des T3D) erzwingen.
Dies würde jedoch verschenkte Rechenzeit auf den PEs bedeuten, die früh mit
der L-loop fertig sind. Dies gilt es natürlich zu vermeiden.
Betrachtet man noch einmal Abbildung 3.6, so erkennt man, daß Updates auf PE
0, die aufgrund der Auswahl von Pivots entstehen, die ebenfalls auf PE 0 sind, sich
nur durch wiederum lokale Elemente in uv und lv auf PE 0 ergeben können. Es
kann also nicht sein, daß sich bei der Elimination des Pivots auf PE 0 ein Update
auf PE 0 durch ein Element in der Pivotzeile auf PE 2 (PE 2 hat keine Elemente in
Zeilen, die PE 0 hat) oder durch ein Element in der Pivotzeile auf PE 1 (PE 0 hat
keine Spalten von PE 1) ergibt. Ebensowenig kann sich ein Update auf Prozessor 0
durch ein Element in ¯L von Prozessor 1 (PE 1 hat keine Elemente in Spalten, die PE
52

3.5 Die Klasse DSLUFactor
0 hat) oder von Prozessor 2 (PE 0 hat keine Zeilen von PE 2) ergeben. Wie man sieht,
gilt das natürlich nur für Pivotelemente, die von PE 0 stammen, da sich z. B. auch ein
Update durch ein Element in der Pivotzeile des Pivots auf PE 2 ergeben kann (PE 0
und PE 2 haben ja dieselben Spalten). Für andere PEs gilt das für PE 0 gesagte jedoch
insofern, als daß auch dort Updates durch Elimination von lokalen Pivots nur lokale
Informationen benötigen.
Es wird also innerhalb der Update-loop eine Unterscheidung in lokale Pivots und
entfernte Pivots getroffen. Zur Elimination von lokalen Pivots ist nur der lokale Teil
von uv und lv nötig, so daß dieser Teil der Update-loop asynchron geschehen kann,
d. h. obwohl evtl. noch nicht alle anderen PEs mit der Abarbeitung der L-loop fertig
sind bzw. deren Daten noch nicht eingetroffen sind. Die Struktur von uv und lv
kommt dieser Abarbeitung entgegen – es muß stets nur der Anfang des MVectors
abgearbeitet werden.
Wie ebenfalls aus Algorithmus 2.1 und Abbildung 3.6 ersichtlich, geschehen Updates
immer an den Schnittpunkten von Zeilen aus ¯L und den Spalten der Pivotzeilen.
Hat man also ein Element ¯l i js , so können Updates an allen Elementen a i j mit j ≠ j s
auftreten, für die a is j ≠ 0 gilt. Bei einer dichtbesetzten Speicherung ist der Algorithmus
zur Ausführung der Updates trivial, man arbeitet für jedes Element von ¯L einfach
die Elemente der zugehörigen Pivotzeile ab, multipliziert die Elemente und speichert
die Differenz zum ursprünglichen Wert wieder in der Matrix ab.
Bei der vorliegenden Speicherung als SVSet ist dies nicht möglich. Hat man z. B.
ein Element ¯l i js und ein Element a is j so kann man das Update-Element a i j nicht durch
einfache Indizierung finden. Es muß innerhalb seiner Zeile (oder Spalte) gesucht
werden. Ist es nicht vorhanden, so liegt ein Fill-in vor. Bei festem ¯l i js muß diese
Suche aber für jedes a is j erfolgen, was aber eine ständige erneute Suche in derselben
Zeile (oder Spalte) impliziert. Dies muß vermieden werden.
Ein Ansatz zur Lösung des Problems ist es, die Elemente der aktiven Submatrix zu
sortieren (wie in [2] geschehen). Diese Methode wird aber in DSLUFactor aufgrund
des Sortieraufwandes nicht angewandt. Stattdessen wurde ein Verfahren gewählt, das
zwar eine höhere Speicherkomplexität, jedoch eine geringere Zeitkomplexität besitzt.
Der Ansatz ähnelt dem bei der Erkennung von Inkompatibilitäten.
Die Vorgehensweise wird also wieder umgekehrt, d. h. statt das Element zu suchen,
das verändert werden soll, wird für jedes Element der zu “updatenden” Matrix
überprüft, ob es verändert wird oder nicht. Dieser Ansatz verhindert jedoch zunächst
nicht das Suchen, sondern verlagert es nur auf die Pivotzeile. Deshalb wird die aktuelle
Pivotzeile in jedem Duchlauf der Update-loop in einen dichtbesetzten Vektor
kopiert, so daß die Updates direkt ohne Suche ausgeführt werden können. Abbildung
3.9 veranschaulicht das Vorgehen. Beim Bearbeiten von Zeile i wird für jedes
Element a i j in workp[j] nachgeschaut, ob dort eine 1 steht. Ist dies der Fall, so ist
53

3 Parallele LR-Zerlegung
workp
-1 0 1
work
a is l 0.0 a is j
¯l i js
a il a ik a i j
Abbildung 3.9: Durchführung der Update-loop
a is j ≠0 und kann dem Vektor work entnommen werden und der Update-Schritt ausgeführt
werden. Ist in workp[j] eine 0, so braucht kein Update ausgeführt zu werden,
da a is j = 0. Die Arrays workp und work werden zu Beginn der Faktorisierung allokiert
und im Falle von workp mit 0 initialisiert. Ist ein Update erfolgt, so wird workp[j]
auf −1 gesetzt, um dies anzuzeigen. Dies ist nötig, da nicht nur “echte” Updates
geschehen können, d. h. Veränderungen der Werte von Nichtnullelementen, sondern
auch Fill-in entstehen kann.
Fill-in wird einem anschließenden Schritt behandelt. Dazu wird für jedes noch
nicht behandelte Nichtnullelement in der Pivotzeile (−1 in workp zeigt dies an) ein
neues Element in A kreiert. Diese zweiteilige Behandlung der Updates hat außerdem
den Vorteil, daß die Anzahl der Fill-Elemente vor der Erzeugung des Fill-ins bekannt
ist (nämlich die Differenz aus der Anzahl der Nichtnullelemente und der im ersten
Teil behandelten Elemente). Daher kann genügend Platz im entsprechenden SVector
geschaffen werden, was die Zahl der realloc()s vermindert.
Der Vektor workp könnte in einer sehr speicherkritischen Umgebung noch wegoptimiert
werden, indem man direkt auf work arbeitet und die ausgezeichneten Werte
0 und −1 durch “nicht mögliche” Fließkommazahlen darstellt.
Sehr selten kann es vorkommen, daß ein Element nach dem Update den Wert 0
hat (was natürlich schön ist). Es kann dann aus seiner Zeile gelöscht werden. In der
Spalte muß es jedoch gesucht werden, was aber aufgrund der geringen Häufigkeit des
Auftretens nicht ins Gewicht fällt.
Es soll an dieser Stelle noch einmal auf die Problematik der doppelten Abspeicherung
aller Elemente zurückgekommen werden. Dadurch, daß die Elemente neben
ihrer zeilenweisen Anordnung auch in Spalten abgespeichert sind (nicht jedoch die
numerischen Werte, die nur einfach vorhanden sind), kommt es zu einigen Problemen,
wie bereits angesprochen. Erstens muß beim Entfernen der Elemente stets nach ih-
54

3.5 Die Klasse DSLUFactor
nen in der Spalte gesucht werden, ebenso beim Entfernen aufgrund von Auslöschung
in der Update-loop. Dem steht aber der wesentlich einfachere Zugriff in der L-loop
gegenüber, der diesen Overhead wettmacht. Bei der lokalen Auswahl von Pivotkandidaten
muß zum Überprüfen der Threshold-Bedingung in der Zeile gesucht werden,
um den numerischen Wert zu ermitteln, ebenso in der L-loop. Im ersteren Fall kann
das (bei relativ dichtbesetzten Matrizen, d. h. ab etwa mehr als 20 Elementen pro Zeile)
zu einem starken Overhead führen, weshalb das Suchen in Spalten abschaltbar ist
(zusätzlich werden die Abfragen nach Akzeptabilität und geringerer Markowitz-Zahl
aus Algorithmus 2.2 vertauscht, um so für “schlechte” Elemente gar nicht erst den
Wert bestimmen zu müssen). Man könnte dem jedoch begegnen, indem man auch
die numerischen Werte doppelt abspeichert. Dann muß jedoch in der Update-loop
bei jeder Veränderung auch die entsprechende andere Inkarnation des Wertes verändert
werden, was wiederum eine Suche impliziert, die hier jedoch aufgrund der hohen
Komplexität der Update-loop sehr schwer wiegt. Aus all diesen Gründen wurde es in
DSLUFactor bei der beschriebenen Struktur belassen.
Algorithmus 3.10 zeigt den Teil der Update-loop, in dem die nicht-lokalen Pivotelemente
eliminiert werden. Der vorhergehende lokale Teil ist analog, es muß
lediglich jede Instanz des Wortes “global” durch “lokal” ersetzt werden. Außerdem
entfallen natürlich die “Warte”-statements.
Aktualisierung von globalen Daten
Durch die Elimination der Pivots ändern sich die Werte einiger Datenstrukturen, die
im nächsten Schritt der Faktorisierung wieder gebraucht werden, und die man nicht
jedesmal neu berechnen will.
Änderungen an Row- und Columncounts Durch das Wegfallen der Elemente in
den Pivotzeilen und -spalten sowie durch Fill-in ändert sich die Anzahl der Elemente
in einigen Zeilen und Spalten. Diese Werte, die Row- bzw. Columncounts, werden
bei der Bestimmung der Markowitz-Zahl von Pivotkandidaten im nächsten Schritt
der Faktorisierung benötigt. Sobald die erste Änderung in einer Zeile oder Spalte
auftritt, wird der alte Wert (d. h. der Wert, der vor dem aktuellen Eliminationsschritt
galt) vermerkt. Dies kann in der L-loop (beim Entfernen von Elementen) oder in der
Update-loop (beim Hinzufügen von Elementen, evtl. auch beim Entfernen) passieren.
Die Differenz zwischen altem und neuem Wert wird dann nach der Update-loop in einer
Methode von DSLURow (für die Rowcounts) bzw. DSLUCol (für die Columncounts)
mittels Gossip ausgetauscht.
55

3 Parallele LR-Zerlegung
for all globale Pivots a is j s
do
for all Elemente a is j im globalen Teil von uv[i s ] mit j ≠ j s do
Warte auf Eintreffen von a is j
workp[j]:= 1;
work[j]:= a is j;
end for
for all Elemente ¯l i js im globalen Teil von lv[j s ] do
Warte auf Eintreffen von ¯l i js
for all Elemente a i j do
if workp[j] = 1 then
workp[j]:= −1;
a i j := a i j − ¯l i js ⋅ work[j];
if a i j = 0 then {dies wird natürlich als a i j ≈ 0 implementiert}
Entferne a i j aus Zeile i
Entferne a i j aus Spalte j
end if
end if
end for
Vergrößere SVector von Zeile i, so daß Fill-in paßt
for all Elemente a is j im globalen Teil von uv[i s ] do
if workp[j] = −1 then
workp[j]:= 1;
else if workp[j] = 1 then
if ¯l i js ⋅ work[j]≠ 0 then
Kreiere Element a i j = −¯l i js ⋅ work[j]
end if
end if
end for
end for
for all Elemente a is j im globalen Teil von uv[i s ] do
workp[j]:= 0;
end for
end for
Algorithmus 3.10: Globaler Teil der Update-loop
Änderungen der IdRings Die beim aktualisieren der Row- und Columncounts
ausgetauschten Informationen werden auch zum Umhängen der Indexelemente in den
IdRings genutzt. Für jede Zeile oder Spalte, in der eine Änderung stattgefunden hat,
56

3.6 Ergebnisse
wird deren Index aus seinem aktuellen Ring ausgehängt und in den neuen eingehängt.
Änderungen der Maximalelemente Bei der Pivotauswahl wird das beträgsmäßig
größte Element jeder Zeile benötigt, anhand derer die Threshold-Bedingung (2.16)
überprüft werden kann. Änderungen hieran können ebenfalls dort auftreten, wo sich
Row- bzw. Columncounts ändern können. Allerdings muß u. U. eine völlige Neuberechnung
des lokalen Maximums erfolgen, wenn sich der Wert des Elementes, das
das aktuelle Maximum darstellt, verringert 15 . Man kann sich diesen Sachverhalt merken
(z. B. indem man den Wert des Maximalbetrages auf −1 setzt), und dann in einem
anschließenden Schritt alle nicht bekannten Maxima ermitteln. Dies erfordert aber
wiederum das Untersuchen von ganzen Zeilen, was aber schon während der Abarbeitung
der Update-loop geschieht. Deshalb werden diese beiden Schritte verquickt.
Dazu wird innerhalb der Update-loop vor Untersuchung der Zeile i für ein ¯l i js der
Maximalbetrag dieser Zeile auf 0 gesetzt und dann während der Abarbeitung neu ermittelt.
Nach Austausch der Ändererungen an den Rowcounts werden die globalen
Maxima der Zeilen mittels Gossip bestimmt. Innerhalb der GossipFunction werden
dabei die empfangenen und lokalen Elemente paarweise verglichen und nur die
größeren im nächsten Schritt weitergesandt.
Die verwendete Vorgehensweise erwies sich als überlegen im Vergleich zu der
nachträglichen Neuberechnung, auch wenn dabei evtl. unnötige Neubestimmungen
passieren. Es müssen jedoch nicht noch einmal die gesamten Zeilen untersucht werden.
3.6 Ergebnisse
In diesem Abschnitt sollen die Ergebnisse beschrieben werden, die mit der im vorigen
Abschnitt beschriebenen Implementierung der Klasse DSLUFactor erzielt wurden.
Zunächst wird die Testumgebung beschrieben, innerhalb derer die Ergebnisse ermittelt
wurden. Anschließend wird auf Erfahrungen mit der gewählten Load-balancing
Strategie eingegangen. Darauffolgend werden die Größen definiert, deren Meßergebnisse
abschließend diskutiert werden.
3.6.1 Testumgebung
Um einen möglichst akkuraten Vergleich verschiedener Implementierungen anstellen
zu können, ist es wichtig, eine ebenso akkurate Umgebung zu definieren, innerhalb
15 Ein Spezialfall hiervon ist natürlich die Elimination oder Auslöschung.
57

3 Parallele LR-Zerlegung
derer die Tests durchgeführt werden.
Die Funktion main() Zu Testzwecken wurde die Klasse DSLUFactor in eine aufrufende
main()-Funktion eingebettet, die Arbeiten zur Vor- und Nachbereitung der
Faktorisierung sowie zur Ergebnisermittlung übernimmt. Sämtliche der im vorigen
Abschnitt beschriebenen Faktorisierungsparameter können durch Kommandozeilenparameter
beeinflußt werden. Hier wird auch die Geometrie des Prozessorgitters festgelegt.
Die Tests wurden mit Prozessorzahlen von 1, 2, 4, 8 und 16 durchgeführt. 16
In allen Tests wurde eine quadratische Aufteilung gewählt, außer bei den Prozessorgittern
1 × 2 sowie 2 × 4. Es sind natürlich auch andere Aufteilungen möglich, diese
wurden jedoch nicht berücksichtigt. Eine Untersuchung in dieser Hinsicht könnte
noch interessant sein. Die Ermittlung sämtlicher Zeiten wurde mittels Methoden der
Klasse Timer durchgeführt, die wie auch SVector etc. im Rahmen von [22] entstanden
ist. Sie benutzt die Funktion times(2).
Matrizen Um das Verhalten der Klasse DSLUFactor zu testen, wurden verschiedene
Experimente mit einer Reihe von Testmatrizen durchgeführt, die aus zwei verschiedenen
Quellen stammen.
Netlib LP Matrizen Zum einen wurden 21 Matrizen aus der linearen Programmierung
gewählt, die aus dem Netlib LP set [4] stammen. Diese Matrizen liegen im .wun-
Format vor, das die Nichtnullelemente zeilenweise als 3-Tupel (Spalte,Zeile,Wert)
abspeichert, wobei der Wert mittels strtod(3) gelesen werden kann. Tabelle 3.1
zeigt einige Eigenschaften der Netlib LP Matrizen.
Harwell-Boeing Matrizen Des weiteren wurden 15 Matrizen aus der Harwell-
Boeing Sparse Matrix Collection [10] ausgewählt, die aus verschiedenen Anwendungsbereichen
stammen. Diese Matrizen liegen im .rua-Format vor, d. h. es sind
reelle unsymmetrische zusammengesetzte 17 Matrizen (“real unsymmetric assembled”).
Unsymmetrisch bezieht sich hier nur auf das Format (es sind wirklich alle
Werte abgespeichert), nicht auf die Matrizen selber. In der Tat sind unter den ausgewählten
Matrizen solche mit symmetrischem Aufbau. Diese könnten zwar effizienter
mit Algorithmen faktorisiert werden, die die Symmetrie ausnutzen, jedoch dienen
sie nichtsdestotrotz als Indikator für die Leistungsfähigkeit eines unsymmetrischen
Faktorisierers. Das .rua-Format ist ein etwas älteres Format, das im Hinblick auf
16 Der T3D läßt nur eine PE-Anzahl p = 2 i zu.
17 im Gegensatz zu nichtzusammengesetzten Matrizen (“unassembled”) aus Finite-Elemente Anwendungen,
die aus kleinen dichtbesetzten Matrizen zusammengesetzt werden.
58

3.6 Ergebnisse
Matrix n a α b α=nc
agg3 1128 22678 20
pilots 1441 18376 13
ganges 1681 7020 4.2
chr15c 1695 6077 3.6
grow22 1760 11215 6.4
bnl1 1792 26845 15
scfxm2 1940 27546 14
scr12 1992 7950 4.0
maros 2180 34254 16
ganges.ob4 2304 28199 12
pilotwe 2452 49135 20
nesm 2488 39095 16
fit1p 2508 9480 3.8
SM-50a 2723 4301 1.6
SM-50b 2723 4603 1.7
osa030 4279 8532 2.0
hanscom17 4967 14018 2.8
hanscom2 4967 13812 2.8
kamin1809 13542 22968 1.7
stocfor3 16675 51412 3.1
kamin2702 19092 33187 1.7
a Dimension der Matrix
b Anzahl der Nichtnullelemente
c Anzahl der Nichtnullelemente pro Zeile/Spalte
Tabelle 3.1: Testmatrizen aus dem Netlib LP set
numerische Anwendungen in FORTRAN entstand. So sind denn auch die Werte der
Nichtnullelemente nicht mittels strtod(3) lesbar, was die Verwendung dieser Matrizen
problematisch macht. Es entstand deshalb im Rahmen dieser Arbeit ein kleiner
Wandler rua2wun, der die Matrizen in das .wun-Format überträgt. Tabelle 3.2 zeigt
einige Eigenschaften der Harwell-Boeing Testmatrizen.
Wahl der Programmparameter Die default-Werte für die frei wählbaren Programmparameter
wurden wie folgt gesetzt. Es werden P = 4 Zeilen oder Spalten
pro gesuchtem Pivotkandidaten durchsucht. Bei p PEs werden maximal c = 4 ⋅ p
Pivotkandidaten pro Eliminationsschritt ausgewählt. Die Pivotkandidaten müssen
59

3 Parallele LR-Zerlegung
Matrix Disziplin n a α b α=nc symmetrisch
steam2 Ölförderung 600 13760 23 ja
mcfe Astrophysik 765 24382 32 nein
jpwh991 Schaltkreissimulation 991 6027 6.1 nein
sherman1 Ölreservoirmodellierung 1000 3750 3.8 ja
sherman2 Ölreservoirmodellierung 1080 23094 21 ja
sherman4 Ölreservoirmodellierung 1104 3786 3.4 ja
mahindas Wirtschaftsmodellierung 1258 7682 6.1 nein
watt1 Erdöltechnik 1856 11360 6.1 nein
watt2 Erdöltechnik 1856 11550 6.2 nein
west2021 Chemotechnik 2021 7353 3.6 nein
orsreg1 Ölreservoirsimulation 2205 14133 6.4 nein
orani678 Wirtschaftsmodellierung 2529 90158 36 nein
sherman5 Ölreservoirmodellierung 3312 20793 6.3 ja
lns3937 Hydrodynamik 3937 25407 6.5 nein
sherman3 Ölreservoirmodellierung 5005 20033 4.0 ja
a Dimension der Matrix
b Anzahl der Nichtnullelemente
c Anzahl der Nichtnullelemente pro Zeile/Spalte
Tabelle 3.2: Testmatrizen aus der Harwell-Boeing Sammlung
die Threshold-Bedingung (2.16) mit u = 0.1 erfüllen. Pivotkandidaten a i j mit einer
Markowitz-Zahl M i j > a ⋅ mincount werden nicht in die Menge globaler Pivots
übernommen. a hat defaultmäßig den Wert 4. Darüberhinaus ist frei wählbar, ob nur
Zeilen oder auch Spalten bei der Pivotsuche berücksichtigt werden sollen. Dies wurde
so gehandhabt, daß für die Testmatrizen aus dem Netlib LP set sowohl Zeilen als auch
Spalten nach Pivotkandidaten durchsucht werden, bei den Matrizen aus der Harwell-
Boeing Sammlung hingegen lediglich Zeilen. Dies liefert durchschnittlich die besten
Ergebnisse.
Sequentielles Programm Das sequentielle Programm wurde in C im Rahmen von
[22] entwickelt und ist stark für sehr dünnbesetzte Matrizen, wie sie in der linearen
Programmierung auftreten, optimiert. Es arbeitet wesentlich performanter als
“general-purpose” Programme wie MA28 [8] oder Y12M [26], so daß es als Implementierung
des besten bekannten sequentiellen Algorithmus angesehen werden kann.
Diese Sicht wird im folgenden konsequent weiter verfolgt, obwohl sie bei manchen
60

3.6 Ergebnisse
Probleminstanzen nicht ganz zutreffend ist. Dazu später mehr.
3.6.2 Load-Balancing
Um die Wirksamkeit des in 3.5.3 beschriebenen Lastausgleichsverfahrens zu überprüfen,
wurden Versuche mit verschiedenen der im letzten Abschnitt aufgeführten
Matrizen durchgeführt. Dazu wurde eine Vergleichsimplementierung erstellt, die in
jedem Eliminationsschritt nicht c p = (d p=n2 s )c Pivotkandidaten mit d p = |I | ⋅ | J| lokal
auswählt, sondern c p = c=p, wenn p die Anzahl der PEs ist, d. h. keinen Lastausgleich
durch Auswahl verschieden großer Mengen von Pivotkandidaten anstrebt. Während
der Faktorisierung wurde dann für jede der Implementierungen die Größe d p von allen
PEs in jedem Eliminationsschritt sowie die Größe n 2 s notiert. d p wird als Größe der
lokalen aktiven Submatrix bezeichnet, n 2 s als Größe der globalen aktiven Submatrix.
Bei einer optimalen Lastverteilung wäre das Verhältnis von d p zu n 2 s genau 1=p auf
allen PEs in jedem Eliminationsschritt, d. h. alle PEs hätten einen gleichgroßen Teil
der globalen aktiven Submatrix. Abbildung 3.10 zeigt einen Ausschnitt 18 der Daten
für die Faktorisierung der Matrix orani678 auf 16 PEs im Vergleich zu einer optimalen
Lastverteilung.
Es wurden dabei in jedem Faktorisierungsschritt für beide Implementierungen das
Minimum sowie das Maximum der Werte d p ermittelt und diese aufgetragen. Eine
kleinere Differenz beider Werte, d. h. ein engeres Anliegen der Kurve am Optimum,
entspricht einer besseren Lastverteilung. Ein ähnliches Bild zeigt sich auch für die
meisten anderen untersuchten Testmatrizen. In der Tat sorgt das Lastausgleichsverfahren
für eine Verringerung der Lastdifferenzen zwischen den Prozessoren. Besonders
im unteren Teil ist gut zu erkennen, wie das Verfahren einer Divergenz der Kurven
entgegenwirkt, was ohne Lastausgleich nicht der Fall ist.
In einigen wenigen Fällen ist jedoch der Lastausgleich machtlos, wie Abbildung
3.11 zeigt. Hier ist die Faktorisierung der Matrix sherman2 auf 16 PEs dargestellt.
Man erkennt, daß schon zu Beginn der Faktorisierung des Nukleus eine stark ungleiche
Verteilung der Nichtnullelemente auf die PEs vorliegt (die Differenz zwischen
Maximum und Minimum ist sehr groß). Hier “versagt” sozusagen die Grid distribution,
d. h. das in 3.4.4 über die statistische Verteilung von Nichtnullelementen gesagte
trifft hier nicht zu. Die Nichtnullelemente der Matrix sherman2 sind so regelmäßig
verteilt, daß ihre Anordnung der der Grid distribution in etwa entspricht. An dieser
Ungleichverteilung kann auch das passive Load-balancing nichts ändern. Man sieht
18 Am Anfang der Faktorisierung, d. h. außerhalb des Ausschnitts in Richtung größerer aktiver Submatrizen
liegen die Daten sehr eng beieinander.
61

3 Parallele LR-Zerlegung
150000
mit Lastausgleich
ohne Lastausgleich
optimale Lastverteilung
Größe der lokalen aktiven Submatrix
100000
50000
0
0
5.0 ⋅ 10 5 1.0 ⋅ 10 6 1.5 ⋅ 10 6
Größe der globalen aktiven Submatrix
2.0 ⋅ 10 6
Abbildung 3.10: Lastverteilung mit und ohne Lastausgleich für die Matrix orani678
auf 16 PEs im Vergleich zu optimaler Lastverteilung
zwar, daß im Vergleich zum unausgeglichenen Algorithmus ein Bestreben nach Ausgleich
da ist, was jedoch nicht von Erfolg gekrönt ist, da die initiale Differenz zu
stark war. Dem beschriebenen Verfahren fehlt anscheinend der Handlungsspielraum,
da mit maximal 64 (4 ⋅ 16) Pivotkandidaten keine große Umverteilung der Last möglich
ist, zumal auch mehr Fill-in bei höherbelasteten PEs entsteht. Eine Erhöhung der
maximalen Zahl an Pivotkandidaten kann das Problem auch nicht lösen, da in diesem
Falle wesentlich schlechtere Pivotreihenfolgen entstehen, die dann die Zeitkomplexität
dominieren.
Aus diesem Grund wurde für die Klasse DSLUFactor noch ein weiteres (statisches)
Lastausgleichsverfahren implementiert, bei dem zu Beginn der Faktorisierung
eine zufällige Permutation der Zeilen und Spalten durchgeführt wird, um so die re-
62

3.6 Ergebnisse
75000
mit Lastausgleich
ohne Lastausgleich
optimale Lastverteilung
Größe der lokalen aktiven Submatrix
50000
25000
0
0
2.5 ⋅ 10 5
5.0 ⋅ 10 5
Größe der globalen aktiven Submatrix
7.5 ⋅ 10 5
Abbildung 3.11: Lastverteilung mit und ohne Lastausgleich für die Matrix sherman2
auf 16 PEs im Vergleich zu optimaler Lastverteilung
gelmäßige Struktur der Matrix “aufzubrechen”. Da zu Beginn der Faktorisierung alle
PEs die gesamte zu faktorisierende Matrix besitzen, ist dies leicht durchzuführen. Es
werden dazu Permutationsarrays σ und τ mittels rand(3) ermittelt, die dann bei der
anschließenden Verteilung anhand der Grid distribution die Sicht auf “virtuelle” Zeilen
und Spalten ermöglichen, d. h. will z. B. PE 0 auf Zeile 0 zugreifen (aus der es ja
Nichtnullelemente zugewiesen bekommt), so greift es auf die Zeile σ[0] zu. Ebenso
wird mit den Spalten verfahren. Diese Umverteilung muß natürlich beim Zugriff
auf die rechte Seite b berücksichtigt werden, was aber keinen wesentlichen Overhead
erzeugt. An die Werte von σ und τ werden keine besonderen Forderungen gestellt,
sie müssen nur eben “einigermaßen zufällig” sein. In der konkreten Implementierung
wurde sogar aus Einfachheitsgründen σ = τ gewählt. Die Lösung von Ax = b
63

3 Parallele LR-Zerlegung
bleibt durch diese Permutation unberührt (bis auf Rundungsfehler), da das in Kapitel
2 bezüglich Operationen auf A gesagte gilt. Die Zufallspermutation ist mittels
eines Programmparameters ausschaltbar.
Abbildung 3.12 zeigt wiederum die bei der Faktorisierung von sherman2 auf 16
PEs angefallenen Daten. Diesmal wurde in beiden Fällen der dynamische passive
Lastausgleich aus 3.5.3 eingesetzt, jedoch einmal mit vorheriger Zufallspermutation
und einmal ohne.
80000
ohne vorherige Permutation
mit vorheriger Permutation
optimale Lastverteilung
Größe der lokalen aktiven Submatrix
60000
40000
20000
0
0
2.0 ⋅ 10 5 4.0 ⋅ 10 5 6.0 ⋅ 10 5
Größe der globalen aktiven Submatrix
8.0 ⋅ 10 5
Abbildung 3.12: Lastverteilung mit und ohne initiale Zufallspermutation für die Matrix
sherman2 auf 16 PEs im Vergleich zu optimaler Lastverteilung
Man kann deutlich den Einfluß erkennen, den das Verfahren auf die Lastverteilung
hat, die mit Zufallspermutation wesentlich ausgeglichener ist. Dies spiegelt sich auch
in der Faktorisierungszeit wider, die bei diesem Problem von 10s auf 7.4s gedrückt
werden konnte.
64

3.6 Ergebnisse
3.6.3 Aufwandsparameter paralleler Algorithmen
Die im nächsten Abschnitt benutzten Begriffe und Metriken, die den Aufwand paralleler
Programme betreffen, sollen hier noch einmal kurz erläutert werden. Ausführlich
sind sie z. B. in [13] oder [11] beschrieben.
Beste sequentielle Zeit Die Funktion T ∗ beschreibt die sequentielle Komplexität
eines Problems. Dies ist der Zeitbedarf des besten bzw. des besten bekannten Algorithmus
und wird im folgenden mit der Zeitfunktion der in 3.6.1 erwähnten Implementierung
gleichgesetzt.
Laufzeit und Speedup T p ist die zeitliche Komplexität eines Algorithmus bei der
Ausführung auf p PEs. Zur Bewertung der Laufzeit kann die Maßzahl des Speedup
herangezogen werden, wobei zwischen zwei Varianten unterschieden wird. Der absolute
Speedup
S a p = T ∗
T p
(3.11)
stellt den Vergleich zum besten sequentiellen Algorithmus an, während der relative
Speedup
S r p = T 1
T p
(3.12)
die Laufzeit des parallelen Algorithmus auf p PEs mit der auf einem PE vergleicht.
Es gilt im Normalfall 1 ≤ S p ≤ p, wobei natürlich S p ≈ p angestrebt wird. In ungünstigen
Fällen kann der Speedup aber auch kleiner als 1 sein, dann spricht man von
Speeddown. Andererseits kann es aber aufgrund verschiedener Effekte auch zu einem
Speedup kommen, der größer als p ist – man spricht dann von superlinearem
Speedup.
Effizienz
Die Effizienz eines parallelen Programms ist definiert als
E p = T 1
p ⋅ T p
= Sr p
p . (3.13)
Sie sagt also etwas darüber aus, zu welchem Grad der angestrebte Speedup von S r p = p
erreicht wird. Im besten Fall gilt E p = 1. 19
19 Bei superlinearem Speedup natürlich auch mehr.
65

3 Parallele LR-Zerlegung
Kosten
Die Kosten eines parallelen Programms sind definiert als
C p = p ⋅ T p . (3.14)
Sie erfassen also, wieviel Zeit das Programm insgesamt verbraucht, also auch die Zeit,
die nicht effektiv genutzt werden kann. Sie geben einen Hinweis darauf, wie effizient
die Ressource “CPU-Zeit” genutzt wird.
3.6.4 Faktorisierungszeiten
In diesem Abschnitt werden die Zeiten vorgestellt, die mit der in dieser Arbeit entstandenen
Implementierung erreicht wurden. Neben den Ausführungszeiten auf dem Cray
T3D wurden außerdem Zeiten auf einer “herkömmlichen” Uniprozessor-Workstation
ermittelt, sowohl für die sequentielle Implementierung (s. Seite 60) als auch für das
auf DSLUFactor basierende Programm. Beide lassen sich ohne Modifikation mittels
einer Präprozessordirektive sowohl auf dem T3D als auch in einer sequentiellen Umgebung
übersetzen. Bei der Workstation handelt es sich um eine Sun Sparcstation 4,
die über einen 110MHz microSPARC II RISC-Prozessor verfügt.
Tabelle 3.3 zeigt nun die Faktorisierungszeiten für die Netlib LP Matrizen, jeweils
sequentiell und auf 1, 2, 4, 8 und 16 PEs. Alle Zeiten sind in Sekunden angegeben.
Es fällt auf, daß die parallele Version auf der Workstation (und auf einem PE) für
alle untersuchten Matrizen signifikant langsamer läuft als die sequentielle – nämlich
bis zu einem Faktor von 5.5 bei der Matrix bnl1. Dies ist vornehmlich auf die höhere
Arbeit zurückzuführen, die das parallele Programm leisten muß. Diese entsteht
bei der Überprüfung der Kompatibilität von Pivotkandidaten, der Bereithaltung von
Maximalbeträgen aller Zeilen und dem Aufbau von verteilten Datenstrukturen (Grid
distribution). All dies muß die sequentielle Version nicht leisten.
Für nahezu alle Matrizen zeigt sich jedoch ein monoton steigender relativer Speedup
von bis zu 5.5 (bei der Matrix nesm). Vergleichsweise gute Speedups ergeben
sich bei den Matrizen, die relativ dichtbesetzt sind, bei denen also ein großer Teil der
Arbeit in der Update-loop verrichtet wird. Leider können diese Geschwindigkeitszuwächse
in fast keinem Fall die Zeitdifferenz bei einem PE wettmachen, wodurch
sich in fast allen Fällen ein absoluter Speeddown ergibt, außer bei den dichtbesetztesten
Matrizen (z. B. S16 a = 1.4 bei der Matrix pilotwe mit 20 Nichtnullelementen pro
Zeile/Spalte). Auffällig ist auch die teils starke Differenz zwischen den Zeiten auf
der Workstation und dem T3D (die T3D-Zeiten sind durchschnittlich 1.6 mal höher
als die auf der Workstation gemessenen). Hierfür ist neben dem nicht vorhandenen
2nd level Cache auf dem T3D die bessere Codegenerierung des Compilers auf der
Workstation verantwortlich.
66

3.6 Ergebnisse
Matrix
Workstation
Cray T3D
T ∗ T 1 T ∗ T 1 T 2 T 4 T 8 T 16
agg3 0.39 1.6 0.46 2.1 1.2 0.78 0.54 0.46
pilots 1.3 1.6 1.6 2.1 1.4 1.2 1.0 0.92
ganges 0.06 0.12 0.04 0.18 0.16 0.17 0.18 0.20
chr15c 0.04 0.11 0.06 0.23 0.20 0.20 0.19 0.28
grow22 0.11 0.38 0.15 0.53 0.36 0.31 0.26 0.33
bnl1 0.64 3.5 0.72 4.3 2.5 1.6 1.0 0.79
scfxm2 0.58 2.7 0.67 3.5 2.1 1.3 0.85 0.67
scr12 0.09 0.23 0.11 0.34 0.30 0.28 0.25 0.33
maros 0.64 2.9 0.79 3.6 2.2 1.3 0.87 0.75
ganges.ob4 0.50 1.8 0.56 2.4 1.5 0.93 0.63 0.57
pilotwe 1.2 3.9 1.3 5.1 3.1 1.8 1.16 0.93
nesm 0.85 3.6 0.94 4.6 2.7 1.6 1.0 0.83
fit1p 0.20 0.56 0.25 0.77 0.70 0.55 0.49 0.47
SM-50a 0.03 0.08 0.03 0.19 0.17 0.17 0.17 0.25
SM-50b 0.04 0.09 0.03 0.20 0.17 0.18 0.17 0.23
osa030 0.05 0.14 0.06 0.32 0.25 0.26 0.23 0.28
hanscom17 0.11 0.38 0.15 0.60 0.54 0.52 0.48 0.55
hanscom2 0.13 0.38 0.16 0.65 0.59 0.57 0.50 0.60
kamin1809 0.18 0.65 0.21 1.2 1.1 1.2 1.0 1.0
stocfor3 0.35 1.1 0.37 2.2 1.8 1.7 1.6 1.8
kamin2702 0.28 1.0 0.32 1.9 1.7 1.7 1.6 1.6
Tabelle 3.3: Faktorisierungszeiten der Matrizen aus dem Netlib LP set in s
Insgesamt kann gesagt werden, daß sich der Einsatz eines parallelen Faktorisierers
für Matrizen aus der linearen Programmierung nicht lohnt, zumal die Testmatrizen
schon zu den dichtbesetzteren dort auftretenden Matrizen zählen.
Für Matrizen aus anderen Anwendungsfeldern gilt dies jedoch nicht, wie die in
Tabelle 3.4 aufgeführten Faktorisierungszeiten zeigen. Vergleicht man zunächst wieder
nur die verschiedenen auf einem PE (bzw. der Workstation) laufenden Versionen,
so fällt wieder auf, daß die sequentielle Version fast immer schneller ist, bis zu einem
Faktor von 3.7 bei der Matrix west2021 und durchschnittlich 1.4-fach schneller. Jedoch
ist die Diskrepanz nicht mehr ganz so stark wie bei den LP-Matrizen. In einigen
Fällen (sherman4, orsreg1, watt1, watt2, sherman3) kann die parallele Version die sequentielle
schon auf einem PE überholen. Besonders stark zeigt sich dies bei der Matrix
watt1. Der Grund hierfür liegt in der “gründlicheren” Suche nach Pivotkandidaten
67

3 Parallele LR-Zerlegung
Matrix
Workstation
Cray T3D
T ∗ T 1 T ∗ T 1 T 2 T 4 T 8 T 16
steam2 0.55 1.1 0.64 1.4 0.90 1.1 1.1 0.67
mcfe 2.1 2.9 2.5 5.4 4.6 2.5 1.9 1.6
jpwh991 4.5 5.7 5.3 6.9 4.9 2.8 2.0 1.8
sherman1 1.1 1.1 1.1 1.4 1.3 1.0 0.79 0.73
sherman2 21 38 24 57 33 17 11 7.4
sherman4 0.93 0.81 1.1 1.1 1.0 0.77 0.64 0.52
mahindas 0.15 0.31 0.17 0.45 0.30 0.30 0.26 0.28
watt1 40 20 49 26 16 14 9.0 7.8
watt2 33 22 41 27 18 13 10 9.0
west2021 0.10 0.37 0.11 0.48 0.42 0.43 0.41 0.39
orsreg1 21 16 33 20 19 14 10 6.3
orani678 3.3 5.8 3.7 7.8 5.6 3.7 2.4 1.8
sherman5 13 24 16 34 17 13 9.0 8.3
lns3937 41 59 51 75 32 26 16 13
sherman3 93 50 122 62 62 38 26 19
Tabelle 3.4: Faktorisierungszeiten der Matrizen aus der Harwell-Boeing Sammlung
in s
mit geringer Markowitz-Zahl bei der auf DSLUFactor basierenden Version. Während
die sequentielle nur 1-2 Zeilen oder Spalten nach Pivotkandidaten durchsucht sind
es bei der parallelen Version 4. Dadurch ergibt sich bei der parallelen Version eine
Pivotreihenfolge, die deutlich weniger Fill erzeugt. Grundsätzlich sind viele der Testmatrizen
aus der Harwell-Boeing Sammlung extrem anfällig für Änderungen in der
Pivotreihenfolge, so daß schon geringe Änderungen an der Parameterwahl (etwa an
der Größe c der Pivotmenge pro Schritt) dramatische Änderungen an der Faktorisierungszeit
bewirken können. Die in Tabelle 3.5 gezeigten Daten bestätigen diese These
vollauf. Sie zeigt die Anzahl der Nichtnullelemente N p in den Faktoren L und R nach
Beendigung der Faktorisierung. 20
Die Anzahl der Nichtnullelemente bei Ausführung auf dem Cray T3D und der
Workstation sind bei N 1 und N ∗ natürlich gleich, so daß hier nur jeweils ein Wert aufgeführt
ist. Unschwer läßt sich erkennen, daß die sequentielle Version z. B. bei watt2
wesentlich mehr Fill erzeugt als die parallele, was zu der weitaus höheren Faktorisierungszeit
beiträgt. Andererseits gibt es auch Fälle (steam2, sherman5), in denen
20 Natürlich abzüglich der Diagonalelemente von L, die den Wert 1 haben und nicht gespeichert werden.
68

3.6 Ergebnisse
Matrix
N ∗ Anzahl der Nichtnullelemente
N 1 N 2 N 4 N 8 N 16
steam2 21159 27691 29090 41376 35876 35189
mcfe 61081 62966 64566 67555 73170 75378
jpwh991 63716 57856 60658 60857 59319 62525
sherman1 27302 22500 24950 25238 25664 28239
sherman2 166821 256115 256183 269923 233492 241970
sherman4 24029 19373 19530 24218 23088 25297
mahindas 10764 10541 10052 11304 10498 13684
watt1 253568 200715 172279 255394 251497 268170
watt2 251258 171479 184473 273958 255987 280074
west2021 10167 11307 11326 12157 11740 12469
orsreg1 220182 168761 224206 240754 237942 299315
orani678 106383 102709 102409 119087 115897 129680
sherman5 164934 188732 192914 215209 214747 242422
lns3937 361183 377892 349373 387633 397088 391292
sherman3 462220 338805 459085 405611 414707 475670
Tabelle 3.5: Anzahl der Nichtnullelemente in den Faktoren L und R für die Matrizen
aus der Harwell-Boeing Sammlung
die parallele Version eine schlechtere Pivotreihenfolge “erwischt”, was sich in den
Faktorisierungszeiten deutlich niederschlägt.
Bei fast allen Matrizen zeigt sich auch hier wieder ein monoton steigender relativer
Speedup (bis zu einem Faktor von 7.7 bei der Matrix sherman2). Im Gegensatz zu den
den LP-Matrizen kann hier aber auch ein teils erheblicher absoluter Speedup erzielt
werden (bis zu einem Faktor von 6.3 bei der Matrix watt1 bzw. 3.9 bei lns3937, wenn
man berücksichtigt, daß die sequentielle Zeit bei watt1 schon über der der parallelen
Version bei einem PE lag).
Besonders interessant sind in diesem Zusammenhang zwei Phänomene, die beim
Übergang von einem auf zwei PEs entstehen. Zum einen kann bei der Matrix lns3937
ein superlinearer Speedup beobachtet werden. Dies ist wieder auf eine unterschiedliche
Pivotreihenfolge zurückzuführen. Bei zwei PEs wird eine Pivotreihenfolge gewählt,
die weniger Fill erzeugt als bei einem PE (die Anzahl der Nichtnullelemente
in L und R ist bei einem PE knapp 10% höher), was glücklicherweise den geringeren,
durch die Parallelisierung entstandenen Zeitaufwand noch weiter drückt, wodurch der
superlineare Speedup entsteht.
Andererseits kann auch der gegenteilige Effekt auftreten, der bei sherman3 be-
69

3 Parallele LR-Zerlegung
sonders gut sichtbar wird. Hier ist die Zeit auf zwei PEs genauso groß wie auf einem
PE, was sich durch die stark erhöhte Zahl von Nichtnullelementen, die durch
eine ungünstige Pivotreihenfolge hervorgerufen wird, erklären läßt. Insgesamt kann
ein Ansteigen der Nichtnullelementeanzahlen bei Erhöhung der PE-Zahl festgestellt
werden (der durchschnittliche Faktor bei 16 PEs im Vergleich zu einem PE liegt bei
1.28). Dies ist auf die größeren Pivotmengen zurückzuführen, die beim Einsatz von
mehr PEs ausgewählt werden. Die schlechte Pivotreihenfolge ist aber nicht allein für
den Effekt bei sherman3 verantwortlich. Hinzu kommt noch ein Load-balancing Problem,
ähnlich dem in Abbildung 3.11 gezeigten. Wendet man jedoch hier die initiale
Zufallspermutation an, ist zwar die Lastverteilung gut, jedoch ergibt sich eine noch
schlechtere Pivotreihenfolge, so daß die Zeit wiederum nicht besser wird (die Zeit auf
einem PE mit Zufallspermutation ist ca. doppelt so hoch wie hier angegeben). 21
Interessant ist auch der Vergleich des in dieser Arbeit entstandenen Algorithmus
mit anderen publizierten Implementierungen. In [2] werden z. B. folgende Ergebnisse
für eine Implementierung auf dem Cray T3D angegeben:
Matrix T ∗ T 4 T 16
steam2 9.9 3.6 1.9
jpwh991 16 6.7 3.2
sherman1 3.0 1.9 1.4
sherman2 81 23 8.1
lns3937 205 82 29
Dies ergibt natürlich erhebliche relative Speedups (bis zu 10 bei der Matrix sherman2)
und damit auch auch sehr gute Effizienzen (bis zu 62%), die von der in dieser
Arbeit entstandenen Implementierung nicht erreicht werden. Wie bereits in 3.6.3 beschrieben,
muß jedoch immer der Vergleich zum “besten bekannten” sequentiellen
Algorithmus gesucht werden. Legt man die in dieser Arbeit benutzte sequentielle Implementierung
zugrunde, so ist der absolute Speedup und damit die Kosten bei dem
auf DSLUFactor basierenden Programm durchweg besser.
Ein Vergleich zu der in [21] vorgestellten Implementierung (die den gleichen Algorithmus
wie [2] einsetzt) ist schwer möglich, obwohl auch dort Zeiten publiziert
sind. Es wird dort nämlich ein MIMD-Parallelrechner eingesetzt, der aus einem Netzwerk
von INMOS T800-20 Transputern aufgebaut ist, wobei die Netzwerktopologie
ein quadratisches Gitter ist. Die mit 20MHz getakteten Transputer sind natürlich nicht
mit den 150MHz DEC Alpha des T3D vergleichbar, weshalb schon die sequentiellen
Zeiten bei [21] teils hundertfach höher sind. Es wird aber auch dort über das An-
21 “caught between a rock and a hard place” würde der Amerikaner wohl sagen.
70

3.6 Ergebnisse
steigen der Zahl von Nichtnullelementen etwa im gleichen Maße wie bei der hier
vorgestellten Implementierung beim Einsatz von mehr PEs berichtet.
Abbildung 3.13 zeigt abschließend noch einmal den absoluten Speedup, der durch
das auf DSLUFactor basierende Programm erzielt wird.
10
LP Matrizen
Harwell-Boeing Matrizen
alle Matrizen
Maximum
Minimum
optimaler Speedup
absoluter Speedup S a p
1
0.1
1
2
8
16
4
Anzahl der Prozessorelemente p
Abbildung 3.13: absoluter Speedup in Abhängigkeit von der Anzahl an Prozessoren
im Vergleich zum optimalen Speedup
Dabei ist einerseits der durchschnittliche absolute Speedup jeweils für die LP-
Matrizen, die Matrizen aus der Harwell-Boeing Sammlung und für alle Testmatrizen
zusammen dargestellt. Außerdem ist der beste absolute Speedup sowie der schlechteste
Speedup von allen Testmatrizen aufgetragen. Hier fällt wieder der “Knick” beim
Übergang von zwei auf vier PEs auf, der durch den superlinearen Speedup bei der
Testmatrix lns3937 und 2 PEs sowie den “unplanmäßigen” Zeitvorsprung schon bei
einem PE bei der Matrix watt1 hervorgerufen wird.
71

3 Parallele LR-Zerlegung
72

4 Parallele Lösung von
Dreieckssystemen
Im vorigen Kapitel wurde ein paralleler Algorithmus zur Zerlegung einer Koeffizientenmatrix
eines linearen Gleichungssystems in eine untere Dreiecksmatrix L und eine
obere Dreiecksmatrix R entwickelt. Wie aus Kapitel 2 bekannt, ist es jedoch zur Lösung
des linearen Gleichungssystems Ax = b ⇔ (LR)x = b, d. h. zur Bestimmung des
Lösungsvektors x darüberhinaus notwendig, zwei Dreieckssysteme mit den Matrizen
L und R zu lösen, was einfach mittels Vorwärts- und Rückwärtssubstitution erreicht
werden kann. Der zeitliche Aufwand zur Durchführung der Vor- und Rückwärtssubstitution
beträgt nur einen geringen Bruchteil des zur Faktorisierung nötigen (im
Promillebereich). In typischen Anwendungen will man aber viele Lösungen mit unterschiedlichen
rechten Seiten berechnen, weshalb der gesamte Aufwand zur Lösung
den zur Faktorisierung sogar überschreiten kann. Ausgehend von einem sequentiellen
Algorithmus soll in diesem Kapitel ein paralleles Programm entwickelt werden, das
aus den Faktoren L und R sowie einer rechten Seite b das Ergebnis x des linearen Gleichungssystems
Ax = b bestimmt. Dabei müssen die Permutationen, die während der
Faktorisierung der Matrix A vorgenommen wurden, beachtet werden, um das richtige
Ergebnis zu erhalten. Sie beschränken sich aber auf die Umsortierung der Elemente
von b bzw. z, so daß sie bei der Entwicklung des Algorithmus keine Rolle spielen und
demzufolge dort auch nicht behandelt werden.
4.1 Sequentieller Algorithmus
Als Ergebnis der LR-Zerlegung einer Matrix A hat man die untere Dreiecksmatrix L
und die obere Dreiecksmatrix R, wobei A = LR. Wegen
b = Ax = (LR)x = L(Rx) ⇒ Ly = b, Rx = y
erhält man die Lösung von Ax = b durch Lösung von Ly = b mittels Vorwärtssubstitution
und anschließende Lösung von Rx = y mittels Rückwärtssubstitution.
73

4 Parallele Lösung von Dreieckssystemen
Vorwärtssubstitution
Hier hat man es mit einem Gleichungssystem der Form
y 1 = d 1
.
. .. .
(4.1)
l n−1,1 y 1 ++ y n−1 = d n−1
l n1 y 1 ++l y n−1 + y n = d n
nn−1
zu tun, wobei gegenüber dem allgemeinen Fall die Koeffizienten l ii = 1 angenommen
wurden, wie sie bei der LR-Zerlegung entstehen. Wie bei (2.3) erhält man auch hier
die Lösung durch Einsetzen von Teillösungen, diesmal von oben her, bis y den endgültigen
Lösungsvektor enthält:
y 1 = d 1
y 2 = d 2 − l 21 y 1
(4.2)
.
l nn−1 y n−1
Man kann jedoch in äquivalenter Weise auch ein spaltenweises Vorgehen wählen, bei
dem man zunächst y = d setzt und dann sukzessive Modifikationen an y vornimmt:
y n = d n − l n1 y 1 −:::−
y i = y i − l i1 y 1 i = 2,:::,n
y i = y i − l i2 y 2 i = 3,:::,n
.
(4.3)
y n = y n − l nn−1 y n−1
Nach jedem der Schritte in (4.3) ist ein y i fertig, so daß es im nächsten Schritt zur
Durchführung der Modifikationen bereitsteht. Welche der Lösungsvarianten man bevorzugt,
hängt von der Datenverteilung von L ab: Bei einer spaltenweisen Aufteilung
böte sich letzgenannte Variante an, anderenfalls erstere. Bei einer stark dünnbesetzten
rechten Seite hat das spaltenweise Vorgehen den Vorteil, daß viele unnötige Operationen
mit y j = 0 bzw. z j = 0 entfallen, da Zeile j von (4.3) nur gerechnet werden
muß, falls y j ≠ 0. In Algorithmus 4.1 ist der Algorithmus zur sequentiellen Durchführung
der Vorwärtssubstitution nach der Spaltenmethode wie in [18] angegeben. Ein
Algorithmus nach der Zeilenmethode ist z. B. in [12] zu finden.
74

4.1 Sequentieller Algorithmus
y:= d;
for j = 1 to n − 1 do
for i = j + 1 to n do
y i := y i − l i j ⋅ y j ;
end for
end for
Algorithmus 4.1: Sequentielle Vorwärtssubstitution nach der Spaltenmethode
Rückwärtssubstitution Bei der Rückwärtssubstitution wird ein Gleichungssystem
Rz = y der Form (2.2) mit der Lösung von (4.1) als rechter Seite gelöst. Dies kann
nach der Zeilenmethode mittels (2.3) geschehen oder aber in Analogie zu (4.3) mit
Hilfe der Spaltenmethode, wobei zuerst z = y gesetzt wird:
z n = z n
r nn
z i = z i − r in z n i = 1,:::,n
z n−1 =
z n−1
r n−1n−1
z i = z i − r in−1 z n−1 i = 1,:::,n
− 1
− 2
(4.4)
z
z n−2 = n−2
r n−2n−2
.
z 1 = z 1 − r 12 z 2
z 1 = z 1
r 11
In diesem Falle müssen die z i jeweils noch durch r ii geteilt werden, da meist r ii ≠ 1.
Algorithmus 4.2 zeigt den Algorithmus zur Durchführung der Rückwärtssubstitution.
z:= y;
for j = n to 2 do
z j := z j=r j j ;
for i = j − 1 to 1 do
z i := z i − r i j ⋅ z j ;
end for
end for
z 1 := z 1=r 11 ;
Algorithmus 4.2: Sequentielle Rückwärtssubstitution nach der Spaltenmethode
75

4 Parallele Lösung von Dreieckssystemen
4.2 Paralleler Algorithmus
Der parallele Algorithmus zur Umsetzung der Algorithmen 4.1 und 4.2 soll mit der in
3.4.1 beschriebenen PCAM-Methode entwickelt werden.
4.2.1 Partitionierung
Auch hier bietet sich, wie in 3.4.2, die Domain decomposition an. Teilt man nämlich
wieder jeweils genau ein Element der Matrizen L und R einem Task zu, so lassen sich
jeweils die inneren for-Schleifen der Algorithmen 4.1 und 4.2 parallelisieren. Die
äußeren Schleifen lassen sich aufgrund dieser Aufteilung nicht parallelisieren, da zur
Berechnung von y j der Wert von y j−1 bzw. zur Berechnung von z j der Wert von z j+1
benötigt wird.
375
Die durch die Elimination kompatibler Pivotelemente in L und R entstandene
Struktur macht es jedoch möglich, mehrere Durchläufe der äußeren Schleife zu einem
zusammenzufassen, der parallel abgearbeitet werden kann. L besitzt folgende
Struktur:
264l 11
0 l 22
.
. .. . ..
s 1
. l s1 +1s 1
+1
0 l s1 +2s 1 +2
.
. .. . ..
0 0
.
00l s1
l s2 s 2
. ..
(4.5)
Die l ii haben alle den Wert 1. Die Zeilen bzw. Spalten 1 bis s 1 sowie s 1 + 1 bis s 2
wurden jeweils in einem Schritt eliminiert. In Algorithmus 4.1 würden die y j mit
j = 1,:::,s 1 beim Durchlauf der äußeren Schleife von j = 1 bis j = s 1 nicht modifiziert,
d. h. sie sind schon vor Beginn der Schleife fertig. Gleiches gilt für die y j mit
j = s 1 + 1,:::,s 2 nach Beendigung des Schleifendurchlaufs für j = s 1 . Mit anderen
Worten, die äußere Schleife von Algorithmus 4.1 kann für j = 1 bis j = s 1 sowie für
j = s 1 + 1 bis j = s 2 usw. parallel ausgeführt werden. Die s i markieren dabei jeweils
einen parallelen Eliminationsschritt. Analog dazu kann man auch bei der Rückwärtssubstitution
verfahren.
76

4.2 Paralleler Algorithmus
4.2.2 Kommunikation
Bei einer wie oben beschriebenen Aufteilung kann man zwei distinkte Kommunikationen
identifizieren:
1. Die von den einzelnen Tasks bei der Durchführung der inneren (parallelen)
Schleife berechneten Modifikationen müssen summiert werden, um den Wert
eines y j bzw. eines z j zu erhalten. Dabei handelt es sich um eine strukturierte,
statische und beidseitig synchrone Kommunikation, die nur zwischen einer
kleinen Menge von Tasks abgewickelt wird, d. h. sie ist auch lokal.
2. Die fertigen y j und z j müssen an die Tasks gesandt werden, die diese bei der
Durchführung “ihrer” inneren Schleife zur Errechnung der Modifikationen benötigen,
also an diejenigen, die Elemente der Spalte j + 1 bzw. j − 1 besitzen.
Dies impliziert ebenfalls eine strukturierte und statische Kommunikation. Sie
ist überdies synchron, da die Berechnung der Modifikationen nicht ohne den
Wert der y j bzw. z j erfolgen kann. Man könnte sich auch eine asynchrone
Kommunikation vorstellen, bei der die Tasks, die den Wert eines y j bzw. eines
z j benötigen, sich diesen von anderen Tasks holen, ohne diese zu informieren.
Jedoch muß der Wert ja fertig sein, so daß es wieder auf eine Synchronisation
hinausläuft. Sie ist auch lokal, da die Werte nur an die Tasks versandt werden
müssen, die diese wirklich brauchen.
4.2.3 Agglomeration und Abbildung
Die idealisierte Herangehensweise in der Partitionierungsphase erweist sich natürlich
als undurchführbar, da eine viel zu feine Granularität gewählt wurde. Besonders bei
der ersteren Kommunikation ergibt dies ein zu hohes Verhältnis zwischen Kommunikation
und Berechnung. Um die Granularität zu erhöhen, bietet es sich an, alle
Tasks einer Zeile, d. h. diejenigen, die Modifikationen an y i bzw. z i für ein i berechnen,
zusammenzufassen. So entfällt die erstere Kommunikation, da die Summe der
Modifikationen an einem y i bzw. z i dann von einem Task berechnet wird. Dieser Task
übernimmt auch den Divisionsschritt z j := z j=r j j , der bei der Rückwärtssubstitution
notwendig ist.
Diese Art der Agglomeration läßt sich noch fortführen, wenn man auch noch mehrere
Zeilen auf einem Task vereinigt, die einem Block (ähnlich wie panels bzw. supernodes
in [18]) angehören. Als ein Block wird eine Menge von benachbarten Zeilen
oder Spalten bezeichnet, die eine diagonale Submatrix auf der Diagonalen besitzen.
Also bilden z. B. die Zeilen 1 bis s 1 aus (4.5) einen Block. Durch eine Blockaufteilung
77

4 Parallele Lösung von Dreieckssystemen
ist genau ein Task für die y i und z i eines Blocks verantwortlich, wodurch mehrere Instanzen
der zweiten Kommunikation, die in 4.2.2 identifiziert wurde (Versenden von
fertigen y i und z i ), zusammengefaßt werden können, d. h. der für die y i bzw. z i eines
Blocks verantwortliche Task verschickt deren Werte an die Tasks, die sie benötigen,
“en bloc”, was Latenzzeiten erspart.
Typischerweise sind mehr Blöcke als PEs vorhanden. Sind bc Blöcke vorhanden,
so werden diese wie folgt auf p PEs verteilt: 1
Block B i → Prozessor q = i mod p, ∀i: i ∈ {0,:::,bc − 1} (4.6)
Die zeilenweise Agglomeration von Tasks legt auch eine zeilenweise Speicherung
der Elemente von L und R sowie den Einsatz einer Zeilenmethode wie in (4.2) nahe.
Dies hat jedoch die oben erwähnten Nachteile bei Gleichungssystemen mit sehr dünnbesetzter
rechter Seite. Deshalb wird eine spaltenweise Speicherung vorgenommen,
bei der die innere Schleife nur bei y j ≠ 0 bzw. z j ≠ 0 durchgeführt werden muß. Um
trotzdem die erstere Kommunikation aus 4.2.2 zu vermeiden, werden die Elemente
zeilenweise auf die PEs verteilt.
Abbildung 4.1 veranschaulicht noch einmal die Blockverteilung exemplarisch für
ein Beispielsystem Ly = d. Die diagonale Linie symbolisiert die l ii = 1. Der unterlegte
Bereich innerhalb der Matrix symbolisiert den Teil, in dem sich Nichtnullelemente
befinden können. Die Zeilen und Spalten wurden in vier Blöcke unterteilt. Der dunkel
unterlegte Bereich stellt die Zeilen des Blocks B 2 dar, deren Elemente allesamt einem
PE zugeordnet sind. Deshalb berechnet dieses PE alle Modifikationen für y B2 (d. h.
alle y i mit i ∈ B 2 ). Die Modifikationen werden spaltenweise von links nach rechts
vorgenommen. Um dies geometrisch zu verdeutlichen, wurde der Vektor y zweimal,
rechts und oben, dargestellt. Man kann sich die Vorgehensweise so vorstellen, daß
die Werte der y B j
über der Matrix benötigt werden, um die Modifikationen an den y Bi
rechts neben der Matrix zu berechnen, jeweils beginnend mit i = j + 1. Wenn dies für
alle Spalten eines Blocks B j geschehen ist, so sind die Elemente y Bi mit i = j +1 fertig
und können vom dafür verantwortlichen PE “nach oben” gesandt werden und so im
nächsten Schritt für weitere Modifikationen zur Verfügung stehen.
In Algorithmus 4.3 ist der parallele Algorithmus zur Vorwärtssubstitution angegeben.
Der Algorithmus zur Rückwärtssubstitution ist analog, nur daß dort eben die
Blöcke vom letzten zum ersten durchlaufen werden und die z j vor dem Versenden
noch durch r j j geteilt werden müssen.
Eine mögliche Veränderung des Algorithmus besteht darin, die Schleife über m
aufzuteilen in einen Teil für m = k + 1, der vor dem Versenden von PE k + 1 mod p
1 Die Blöcke und Prozessoren seien dabei in Hinblick auf eine Implementierung von 0 bis bc − 1 bzw.
von 0 bis p − 1 numeriert.
78

4.2 Paralleler Algorithmus
y B0 y B1 y B2 y B3
y B0
B 0
B 1
y B1
B 2
y B2
B 3
B 0 B 1 B 2 B 3
y B3
Abbildung 4.1: Blockverteilung zur Lösung von Ly = d
ausgeführt wird, und einen für die restlichen m, der nach dem Versenden ausgeführt
wird. Auf diese Art werden die anderen PEs schneller mit dem Ergebnis von y Bk+1
versorgt und können so früher weiterrechnen. Andererseits muß dann die umgebende
Schleife über j zweifach ausgeführt werden. Außerdem muß sichergestellt sein, daß
die Werte von l i j für i ∈ B k+1 zusammenhängend abgespeichert wurden, um sie nicht
noch innerhalb von L suchen zu müssen. Beide Varianten (mit und ohne Aufteilung
der Schleife über m) wurden implementiert. Die Variante mit Aufteilung der Schleife
brachte aber keine Verbesserung der Performance, so daß sie im folgenden nicht mehr
behandelt wird.
79

4 Parallele Lösung von Dreieckssystemen
y:= d;
for k = 0 to bc − 2 do
Warte auf y Bk
for all j ∈ B k do
if y j ≠ 0 then
{me ist lokales PE, p die Anzahl der PEs}
for all m ∈ {k + 1,:::,bc − 1} mit m mod p = me do
for all l i j ≠ 0 mit i ∈ B m do
y i := y i − l i j ⋅ y j ;
end for
end for
end if
end for
if verantwortlich für Block k + 1 then
versende y Bk+1 an alle PEs
end if
end for
Algorithmus 4.3: Parallele Vorwärtssubstitution
4.3 Implementierung des parallelen Algorithmus
Datenverteilung Die Datenverteilung wird als separate Methode implementiert,
d. h. unabhängig vom eigentlichen Lösungsalgorithmus. Oft will man nämlich viele
Gleichungssysteme mit der gleichen Koeffizientenmatrix A aber unterschiedlichen
rechten Seiten b lösen. In diesem Fall muß man die Verteilung der Nichtnullelemente
in L und R nicht jedesmal neu vornehmen, sondern kann dies einmalig zu Beginn der
Lösung machen.
Da die Nichtnullelemente von L und R nach der LR-Zerlegung auf allen PEs vollständig
repliziert sind, kann die Neuverteilung gemäß (4.6) lokal erfolgen. Die Erfassung
der dafür nötigen Information über die Blockstruktur wurde in die Faktorisierung
eingebaut, und zwar in Form eines DataArrays, das die einzelnen s i wie in (4.5)
festhält.
Zum Zwecke der Neuverteilung werden die Elemente aus den MVectors lv und
uv (die die Nichtnullelemente von L bzw. R enthalten) in DataArrays von Strukturen,
die ein int (für den Zeilen- bzw. Spaltenindex) sowie ein double (für den Wert)
enthalten, kopiert. Jedes PE greift sich nur die für es relevanten Nichtnullelemente
heraus. Dabei wird gleichzeitig eine explizite Permutation vorgenommen, so daß die
Indexwerte die permutierten Matrizen reflektieren.
80

4.3 Implementierung des parallelen Algorithmus
Des weiteren werden die bei der Rückwärtssubstitution benötigten Diagonalelemente
r ii von R extrahiert, d. h. nicht in den DataArrays bei den anderen r i j mit i ≠ j
belassen, sondern in einem eigenen DataArray untergebracht, damit man sie bei der
Rückwärtssubstitution nicht erst suchen muß. Es wird auch gleich der reziproke Wert
abgespeichert, da die Fließkommadivision bei dem in den PEs des T3D eingesetzten
Mikroprozessor um ein Vielfaches länger dauert als eine Multiplikation, die dann bei
der (potentiell vielfach durchgeführten) Rückwärtssubstitution anfällt. 2
Die Vektoren d, y und z werden auf jedem PE in demselben Array von doubles
mit einer auf allen PEs gleichen Startadresse untergebracht.
Permutationen Die Permutation von b nach d wird wieder explizit durchgeführt,
und zwar so, daß sich jedes PE nur die Werte von d i = b πi der Blöcke in das oben beschriebene
Array kopiert, an denen es Modifikationen ausführt. Bei der Permutation
von z nach x werden alle Werte der z j nach x ρ j
kopiert, da z komplett auf allen PEs
repliziert ist.
Vor- und Rückwärtssubstitution Bei der Vorwärtssubstitution werden die Blöcke
0 und bc − 2 gesondert behandelt. Im Falle von Block 0 entfallen die “Warte”-
statements und bei der Behandlung von Block bc − 2 kann schon die Multiplikation
der y Bbc−1 mit den 1=r ii für i ∈ B bc−1 erfolgen, die dann schon einen Teil von z bilden.
Besonders kritisch im Hinblick auf die Performance ist die Synchronisation (die
“Warte”-statements in Algorithmus 4.3) sowie das Versenden der fertigen Segmente
von y. Da die Anfangsadressen des y repräsentierenden Arrays auf allen PEs gleich
sind, kann das Versenden mit einem für alle PEs gleichen Aufruf von shmem_put
erfolgen.
Die Synchronisation gestaltet sich hingegen schwieriger. Es wäre z. B. möglich,
ein weiteres Array zu führen, das für jeden Block eine empty/full-Semantik realisiert.
Das bedeutet, daß zu Beginn des Lösens alle Elemente dieses Arrays auf 0 gesetzt
würden, und dann zusätzlich zu den y Bk mittels eines weiteren shmem_put noch ein
von 0 verschiedener Wert in die k-te Stelle des Arrays geschrieben würde, der das
Eintreffen des Segments von y signalisiert. Das Problem bei einem solchen Vorgehen
ist das zweite shmem_put. In [16] wird eine Latenzzeit von wenigstens 1µs für die
SHMEM-Routinen angegeben. Das entspricht 150 Taktzyklen, während denen maximal
150 Fließkommamultiplikationen (realistisch etwa 50 Fließkommamultiplikationen)
berechnet werden könnten. Legt man eine sehr dünnbesetzte Struktur der Matrix
L von etwa einem Nichtnullelement pro Zeile oder Spalte zugrunde, so könnten während
der Initiierung eines shmem_put mehr als 150 Spalten abgearbeitet werden. Aus
2 Auf Kosten der Genauigkeit, auf die wieder zugunsten der Effizienz verzichtet wird.
81

4 Parallele Lösung von Dreieckssystemen
diesem Grund wird das Array von y selber zur Synchronisation benutzt. Zu diesem
Zweck wird zu Beginn der Vorwärtssubstitution eine “nicht mögliche” Fließkommazahl
3 an die Stellen des y repräsentierenden Arrays geschrieben, an die später von
anderen PEs mittels shmem_put geschrieben wird, die also nicht innerhalb der dem
lokalen PE zugeordneten Blöcke liegen.
Die “Warte”-statements sind dann Spin-wait-loops auf eine “volatile” deklarierte
Variable 4 , die die Adresse des y j enthält, auf das gewartet werden soll. Dies ist effizienter
als die SHMEM-eigene Spin-wait Funktion shmem_wait. Da ja ganze Segmente
von y versandt werden (die auch in stets derselben Reihenfolge abgearbeitet
werden), wäre es möglich, das NaN nur in das erste der y j eines Blocks zu schreiben
und auch nur auf das erste der y j zu warten (und dann alle weiteren ohne Synchronisation
abzuarbeiten). Dies erwies sich aber als nicht machbar, da die y j u. U. so
langsam ausgeliefert werden, daß zwar das erste der y j (auf das synchronisiert wird),
aber noch nicht alle weiteren eingetroffen sind, obwohl diese schon (aufgrund der
fehlenden Synchronisation) fälschlicherweise gelesen werden. Andererseits könnte
man auch ausschließlich auf das letzte y j eines Blocks synchronisieren, um so sicherzustellen,
daß alle Daten eingetroffen sind. Eine solche Synchronisation wurde noch
nicht implementiert. Es wird aber für diese Variante keine Leistungsverbesserung erwartet,
da in diesem Falle die bereits eingetroffenen ersten y j nicht zur Berechnung
von Modifikationen benutzt werden können, solange die anderen noch “unterwegs”
sind.
Die Rückwärtssubstitution wird prinzipiell analog zur Vorwärtssubstitution implementiert.
Dabei muß kein Block gesondert behandelt werden. Die einzelnen PEs
führen vor dem Verschicken die Multiplikation der z j mit 1=r j j durch.
4.4 Ergebnisse
Testumgebung Um realistische Zahlen zu erhalten, wurden zwei verschiedene
Tests mit den Matrizen aus 3.6.1 durchgeführt. Zum einen mußte 500 mal die Lösung
für das Gleichungssystem mit dichtbesetzter rechter Seite berechnet werden, wobei
b i =p1 + i gesetzt wurde. Zum anderen mußte 500 mal das Gleichungssystem mit
dünnbesetzter rechter Seite gelöst werden, wobei für b im j-ten Schritt ein Einheitsvektor
mit b j = 1 und b i = 0 für alle i≠ j genommen wurde. Dies wurde wieder für das
sequentielle Programm aus 3.6.1 und die parallele Implementierung auf der in 3.6.4
beschriebenen Workstation sowie dem T3D durchgeführt.
3 Ein Bitmuster, das keinen reellen Zahlenbereich repräsentiert, auch “Not a Number”, kurz NaN
genannt.
4 Um nicht aus dem Cache oder Registern zu lesen.
82

4.4 Ergebnisse
Laufzeiten Die Ergebnisse bei dünnbesetzter rechter Seite für die Netlib LP Testmatrizen
sind in Tabelle 4.1 dargestellt. Die parallele Implementierung ist häufig
Matrix
Workstation
Cray T3D
T ∗ T 1 T ∗ T 1 T 2 T 4 T 8 T 16
agg3 3.1 1.5 3.4 1.5 1.5 1.5 1.4 2.1
pilots 5.2 4.6 4.7 5.3 4.9 3.2 3.0 3.5
ganges 1.0 1.1 0.6 0.9 1.0 1.1 1.4 2.0
chr15c 1.1 1.2 0.9 1.1 1.2 1.3 1.5 2.2
grow22 1.2 1.2 1.0 1.1 1.3 1.3 1.4 2.0
bnl1 5.7 2.2 5.1 2.4 2.2 2.0 2.1 2.7
scfxm2 4.9 2.2 4.2 2.2 2.6 2.7 2.4 2.7
scr12 1.3 1.8 1.2 1.8 1.8 1.8 2.0 2.5
maros 4.2 2.3 3.8 2.3 2.3 2.1 2.3 3.6
ganges.ob4 3.1 2.2 2.6 2.1 2.3 2.1 2.5 3.1
pilotwe 6.1 2.8 6.0 2.7 2.7 3.6 3.1 3.3
nesm 4.2 2.6 3.8 2.6 2.6 2.7 2.7 3.4
fit1p 1.5 1.6 1.1 1.4 1.7 1.8 2.2 3.0
SM-50a 1.3 1.4 0.8 1.1 1.2 1.4 1.9 3.4
SM-50b 1.4 1.4 0.9 1.1 1.3 1.4 1.9 2.7
osa030 1.9 2.4 1.5 1.8 1.9 2.0 2.7 3.8
hanscom17 3.1 3.6 3.1 3.3 3.2 3.4 4.0 5.6
hanscom2 3.4 3.8 3.1 3.6 3.6 3.6 4.0 5.9
kamin1809 7.1 8.4 5.9 7.2 8.0 8.2 10.8 14.5
stocfor3 8.9 10.1 7.3 8.5 8.8 9.4 11.2 16.1
kamin2702 10.9 12.1 8.4 12.8 13.0 15.0 19.0 25.4
Tabelle 4.1: Lösungszeiten für die Netlib LP Matrizen bei dünnbesetzter rechter Seite
in s
schon bei einem PE schneller als die sequentielle Implementierung (bis zu einem
Faktor von 2.6 bei der Matrix bnl1), vor allem bei vergleichsweise dichtbesetzter Matrix.
Allerdings kann für fast alle Matrizen kein relativer Speedup erzielt werden.
Im Gegenteil, es ergibt sich sogar häufig ein relativer Speeddown. Dies ist auf die
Anhäufung von Kommunikationskomplexität bei Hinzunahme von mehr PEs zurückzuführen,
die bei diesen dünnbesetzten Matrizen und der dünnbesetzten rechten Seite
die Berechnungskomplexität dominiert. Außerdem wurden zur Lösung die Faktoren
aus der parallelen Faktorisierung benutzt, die eine ansteigende Anzahl von Nichtnullelementen
aufweisen, weshalb bei mehr PEs durchschnittlich mehr Arbeit bei der
83

4 Parallele Lösung von Dreieckssystemen
Lösung verrichtet werden muß.
In Tabelle 4.2 sind die Ergebnisse für die Harwell-Boeing Testmatrizen bei dünnbesetzter
rechter Seite angegeben. Vergleicht man zunächst nur die Zeiten auf einem
Matrix
Workstation
Cray T3D
T ∗ T 1 T ∗ T 1 T 2 T 4 T 8 T 16
steam2 3.1 3.0 2.8 2.6 2.2 2.4 1.9 2.2
mcfe 4.1 8.0 3.9 7.2 5.4 4.2 3.7 4.8
jpwh991 7.7 7.2 8.4 6.1 4.1 3.1 1.9 3.7
sherman1 2.5 2.2 2.2 2.1 2.1 1.7 1.8 2.5
sherman2 21.7 20.2 22 16.0 12.0 7.7 6.2 7.0
sherman4 2.2 1.9 1.8 1.7 1.7 1.3 1.8 2.4
mahindas 1.3 1.6 1.1 1.4 1.3 1.3 1.4 2.0
watt1 30.8 25.2 35 21.8 11.8 10.5 8.6 9.5
watt2 30.0 19.2 33 16.3 13.4 12.3 9.1 9.6
west2021 2.0 2.1 1.8 2.3 2.4 2.2 2.3 3.1
orsreg1 30.7 24.3 37 20.4 18.1 10.7 9.4 10.4
orani678 10.1 9.0 9.1 7.9 6.6 6.1 6.0 7.5
sherman5 10.4 15.6 10 13.0 9.3 7.2 7.8 9.9
lns3937 41.4 47.8 54 38.6 25.7 18.5 14.5 16.0
sherman3 37.9 28.1 43 23.4 23.5 14.0 13.7 14.8
Tabelle 4.2: Lösungszeiten für die Matrizen aus der Harwell-Boeing Sammlung bei
dünnbesetzter rechter Seite in s
Prozessor, so erkennt man, daß die parallele Implementierung bei vielen Matrizen
schneller ist als die sequentielle (bis zu einem Faktor von 1.6 bei der Matrix watt2).
Dies ist u. a. darauf zurückzuführen, daß die Lösungen jeweils ausgehend von den
Faktorisierungen berechnet wurden, die auch von dem jeweiligen Programm vorgenommen
wurden. Das bedeutet, daß das sequentielle Programm bei manchen Matrizen
durch die höhere Anzahl von Nichtnullelementen (vgl. Tabelle 3.5) in den Faktoren
L und R mehr Arbeit zu verrichten hat. 5 Das gilt natürlich auch umgekehrt (z. B.
bei der Matrix sherman5).
Bei den Matrizen aus der Harwell-Boeing Sammlung ist fast immer ein relativer
Speedup bis zu 8 PEs festzustellen (von bis zu 3.2 bei der Matrix jpwh991). Ab 16 PEs
beginnt wieder der Kommunikationsaufwand die Berechnungszeit zu dominieren.
5 Anders als bei den Netlib LP Matrizen, bei denen die Anzahl der Nichtnullelemente in den Faktoren
von sequentieller zu paralleler Implementierung nicht so stark abweicht.
84

4.4 Ergebnisse
Tabelle 4.3 faßt die Ergebnisse für die Netlib LP Testmatrizen bei dichtbesetzter
rechter Seite zusammen. Bei dieser Konstellation liegen die parallele und sequenti-
Matrix
Workstation
Cray T3D
T ∗ T 1 T ∗ T 1 T 2 T 4 T 8 T 16
agg3 4.8 5.6 5.5 5.1 3.8 2.8 2.5 2.8
pilots 8.3 8.2 8.4 8.0 5.8 4.5 4.1 4.4
ganges 1.9 2.2 2.0 2.8 2.7 2.7 2.9 3.3
chr15c 2.1 2.4 2.2 2.6 2.5 2.3 2.4 2.9
grow22 3.0 3.3 2.9 3.7 3.3 3.0 2.9 3.4
bnl1 6.8 7.3 6.5 7.3 5.4 4.3 3.9 4.1
scfxm2 6.5 7.0 6.5 7.1 5.3 4.4 4.0 4.4
scr12 2.9 3.3 3.1 3.5 3.2 2.9 3.0 3.9
maros 7.7 8.2 7.6 8.0 6.1 4.7 4.3 4.7
ganges.ob4 6.6 6.8 6.5 7.1 5.5 4.6 4.4 5.0
pilotwe 12.1 10.9 10.6 10.3 7.2 5.8 5.1 5.6
nesm 8.5 9.3 8.9 9.2 6.7 5.4 5.0 5.4
fit1p 2.6 3.2 2.5 3.3 3.6 3.4 3.9 4.5
SM-50a 1.9 2.1 1.8 2.3 2.8 3.0 3.5 4.2
SM-50b 2.0 2.4 2.0 2.5 3.0 3.1 3.6 4.3
osa030 3.3 3.4 3.4 3.7 4.3 4.4 5.2 6.2
hanscom17 6.5 6.7 7.5 9.0 8.5 8.3 8.8 10.2
hanscom2 6.4 6.7 7.4 9.3 8.7 8.4 8.7 10.3
kamin1809 11.9 11.5 12.5 15.0 16.9 17.6 20.2 24.3
stocfor3 22.9 21.6 21.7 26.9 25.5 24.6 25.2 29.5
kamin2702 17.7 16.6 17.8 22.0 24.5 25.9 29.7 36.6
Tabelle 4.3: Lösungszeiten für die Netlib LP Matrizen bei dichtbesetzter rechter Seite
in s
elle Implementierung bei einem Prozessor nahezu gleichauf, wobei die sequentielle
meist leicht schneller ist. Interessant sind dabei die letzten drei Zeilen. Obwohl die
parallele Implementierung bei allen drei Matrizen (kamin1809, stocfor3, kamin2702)
auf der Workstation geringfügig schneller ist als die sequentielle Version, ist sie auf
dem T3D und einem PE deutlich langsamer. Das sequentielle Programm ist dabei im
Vergleich zur Workstation bei der Matrix stocfor3 sogar schneller. Beim parallelen
Programm haben hier die (unnötigen, aber trotzdem ausgeführten) Synchronisationsabfragen
sowie weitere kleine redundante Operationen (die auf der Workstation wie
die Synchronisation mittels Präprozessordirektive entfernt wurden) einen starken Ein-
85

4 Parallele Lösung von Dreieckssystemen
fluß.
Anders als bei der dünnbesetzten rechten Seite ergeben sich hier häufig relative
sowie absolute Speedups bis zu einer PE-Anzahl von 8 (relative Speedups von bis zu
2.0 bei den Matrizen agg3 und pilotwe, die gleichzeitig die dichtbesetztesten sind).
Bei den sehr dünnbesetzten Matrizen (z. B. kamin2702) ergeben sich allerdings nur
Speeddowns. Dies liegt wieder am hohen Verhältnis zwischen Kommunikation und
Berechnung, das ab 16 PEs auch bei den “guten” Matrizen dominant wird.
In Tabelle 4.4 sind die Ergebnisse für die Testmatrizen aus der Harwell-Boeing
Sammlung bei dichtbesetzter rechter Seite aufgeführt. Betrachtet man zunächst nur
Matrix
Workstation
Cray T3D
T ∗ T 1 T ∗ T 1 T 2 T 4 T 8 T 16
steam2 4.5 5.0 4.0 5.2 3.6 3.3 2.5 2.7
mcfe 10.6 11.6 9.8 10.5 7.0 5.3 4.6 5.2
jpwh991 11.6 11.6 11.6 9.8 6.7 4.7 3.9 4.4
sherman1 5.4 5.3 5.0 4.5 3.6 2.8 2.7 3.1
sherman2 31.1 50.0 28.1 39.7 23.2 14.6 9.1 8.8
sherman4 5.2 4.0 4.7 3.9 3.1 2.8 2.6 3.1
mahindas 2.6 2.7 2.3 3.0 2.5 2.4 2.4 2.9
watt1 46.8 40.0 49.4 32.8 17.7 15.6 11.0 10.9
watt2 46.8 33.5 47.3 28.5 18.8 16.5 11.1 11.1
west2021 3.1 3.7 3.0 4.8 4.3 3.9 4.0 4.6
orsreg1 43.4 34.2 47.7 29.2 23.0 15.4 11.4 11.9
orani678 21.2 20.8 18.2 18.2 12.9 11.2 9.4 9.4
sherman5 34.0 36.8 32.7 31.7 20.2 14.6 11.6 12.4
lns3937 67.5 74.5 73.3 65.3 37.9 28.0 19.3 18.3
sherman3 82.9 64.3 91 56.7 45.4 26.3 19.2 19.1
Tabelle 4.4: Lösungszeiten für die Matrizen aus der Harwell-Boeing Sammlung bei
dichtbesetzter rechter Seite in s
wieder die Performance auf der Workstation, so ergibt sich ein sehr differenziertes
Bild. Keines der beiden Programme ist durchschnittlich schneller als das andere, aber
für einzelne Matrizen ergeben sich starke Unterschiede. Bei der Matrix sherman2
z. B. ist die sequentielle Implementierung 1.6 mal schneller, bei der Matrix watt2
dagegen 1.4 mal langsamer. Dies hängt u. a. wiederum mit der stark unterschiedlichen
Anzahl von Nichtnullelementen in den Faktoren L und R zusammen, die sich hier
noch ausgeprägter als bei der dünnbesetzten rechten Seite bemerkbar macht.
Aufgrund der erheblich höheren Berechnungskomplexität durch die dichtbesetzte
86

4.4 Ergebnisse
rechte Seite kann mehr Parallelität genutzt werden, weshalb sich beim T3D relative
Speedups von bis zu 4.5 bei der Matrix sherman2 ergeben. Bei den Matrizen sherman2
und lns3937 kann sogar ein Speedup bis zu einer PE-Anzahl von 16 erreicht
werden.
Zum Abschluß soll die mit dem in dieser Arbeit entwickelten Programm zur Vorund
Rückwärtssubstitution erzielte Skalierung grafisch dargestellt werden. Dies ist in
Abbildung 4.2 für die Lösung mit dünnbesetzter rechter Seite und in Abbildung 4.3
für die Lösung mit dichtbesetzter rechter Seite geschehen.
10
absolute Verbesserung von Np=Tp
1
0.1
1
LP Matrizen
Harwell-Boeing Matrizen
alle Matrizen
Maximum
Minimum
optimale Verbesserung
2
4
Anzahl der Prozessorelemente p
8
16
Abbildung 4.2: absolute Verbesserung der Anzahl der abgearbeiteten Nichtnullelemente
pro Zeit bei der Lösung mit dünnbesetzter rechter Seite in Abhängigkeit von
der Anzahl an Prozessoren im Vergleich zur optimalen Verbesserung
Um den Einfluß der verschiedenen Anzahlen an Nichtnullelementen in den Faktoren
L und R zu berücksichtigen, wurde hier nicht der absolute Speedup aufgetragen,
87

4 Parallele Lösung von Dreieckssystemen
sondern die Verbesserung der Anzahl der abgearbeiteten Nichtnullelemente pro Zeit
(N p=T p ). Als Verbesserung wird hier das Verhältnis (N p=T p )=(N ∗=T ∗ ) definiert.
10
absolute Verbesserung von Np=Tp
1
LP Matrizen
Harwell-Boeing Matrizen
alle Matrizen
Maximum
Minimum
optimale Verbesserung
0.1
1
2
8
16
4
Anzahl der Prozessorelemente p
Abbildung 4.3: absolute Verbesserung der Anzahl der abgearbeiteten Nichtnullelemente
pro Zeit bei der Lösung mit dichtbesetzter rechter Seite in Abhängigkeit von
der Anzahl an Prozessoren im Vergleich zur optimalen Verbesserung
Interessant ist hierbei der Verlauf der maximalen Verbesserung, der bei der dünnbesetzten
rechten Seite steiler verläuft, obwohl durchschnittlich schlechtere Verbesserungen
erzielt werden. Dies wird hauptsächlich durch die bessere Performance der
parallelen Implementierung bei vergleichsweise dichtbesetzten Matrizen (agg3, bnl1,
sherman2 etc.) hervorgerufen.
Insgesamt kann gesagt werden, daß sich der Einsatz eines parallelen Lösers desto
mehr lohnt, je dichtbesetzter die Koeffizientenmatrix und die rechte Seite sind. Speziell
für Matrizen aus der linearen Programmierung lohnt sich der Einsatz also nicht,
88

4.4 Ergebnisse
da keine Geschwindigkeitsvorteile erzielt werden können. Dies liegt an der geringen
Berechnungskomplexität, die nicht genügend Potential an Parallelität bietet, um nicht
von der vergleichsweise hohen Kommunikationskomplexität aufgewogen zu werden.
Bei Matrizen aus anderen Anwendungsfeldern lohnt sich der Einsatz hingegen schon,
wie die mit den Matrizen aus der Harwell-Boeing Sammlung erzielten Ergebnisse
belegen.
89

4 Parallele Lösung von Dreieckssystemen
90

5 Zusammenfassung
In dieser Arbeit wurde gezeigt, daß sich der Einsatz eines parallelen Programms zur
Lösung von linearen Gleichungssystemen mit sehr dünnbesetzter Koeffizientenmatrix
wie sie in der linearen Programmierung auftreten, d. h. mit etwa weniger als 10
Nichtnullelementen pro Zeile oder Spalte vor und nach der Faktorisierung, mit heute
verfügbaren massiv-parallelen Rechnern nicht lohnt. Dies ist auf das bei diesen Probleminstanzen
zu hohe Verhältnis von Kommunikations- zu Berechnungskomplexität
zurückzuführen.
Bei “durchschnittlich” dünnbesetzten Matrizen aus anderen Disziplinen (z. B. der
Ölreservoirmodellierung) [10], d. h. mit etwa 100 Nichtnullelementen pro Zeile oder
Spalte vor und nach der Faktorisierung, können dagegen mit dem in dieser Arbeit entwickelten
Programm erhebliche absolute Speedups erzielt werden, die teils deutlich
höher als die einer anderen vergleichbaren Publikation sind [2].
Der Einsatz einer Pivotauswahl mit dynamischem, passivem Load-balancing [23]
in Verbindung mit einer Grid distribution zur Verringerung der Kommunikationskomplexität
und zum statischen Lastausgleich hat sich als erfolgreich erwiesen, bietet
jedoch noch experimentellen Spielraum. Bei wenigen Problemen kann das passive
Load-balancing die durch eine bezüglich der Grid distribution ungünstige Struktur
der Matrix hervorgerufene schlechte Lastverteilung nicht wiedergutmachen. Die in
dieser Arbeit vorgeschlagene initiale Zufallspermutation versucht dem entgegenzuwirken.
Auch die Verwendung einer stark asynchronen, nicht kooperativen Kommunikationsstruktur
in der L- und Update-loop hat sich als sehr effizient erwiesen.
Das in dieser Arbeit entwickelte Programm zur Vor- und Rückwärtssubstitution
nutzt die Blockstruktur der Dreiecksmatrizen aus und versucht, eine hohe Effizienz
durch Vermeidung und Integration von Kommunikationsvorgängen zu erreichen. Es
ist häufig auf einem Prozessor schon schneller als eine hochoptimierte sequentielle
Implementierung [22]. Trotz der sehr geringen Berechnungskomplexität lassen sich
für “durchschnittlich” dünnbesetzte Matrizen und rechte Seiten gute Speedups erzielen.
Aufgrund der durchweg positiven Ergebnisse der Implementierung für Matrizen
aus anderen Bereichen als der linearen Programmierung wird dem geplanten Einsatz
91

5 Zusammenfassung
für die Lösung partieller Differentialgleichungen mit hohen Erwartungen entgegengesehen.
92

Literaturverzeichnis
[1] ALAGHBAND, G.: Parallel Pivoting Combined with Parallel Reduction and
Fill-in Control. Parallel Computing, 11:201–232, 1989.
[2] ASENJO, R. und E. L. ZAPATA: Sparse LU factorization on the Cray T3D.
In: HERTZBERGER, BOB und GIUSEPPE SERAZZI (Herausgeber): High-Performance
computing and networking: International Conference and Exhibition,
Milan, Italy, May 3–5, 1995: proceedings, Lecture Notes in Computer Science,
Seiten 690–696. Springer-Verlag, 1995.
[3] BARRIUSO, RAY und ALLAN KNIES: SHMEM User’s Guide for C. Cray Research
Inc., August 1994. Revision 2.2.
[4] BROWNE, SHIRLEY, JACK DONGARRA, ERIC GROSSE und TOM ROWAN:
The Netlib Mathematical Software Repository. D-Lib magazine: the magazine
of the Digital Library Forum, September 1995. Online-Version:
http://www.dlib.org/dlib/september95/netlib/09browne.html.
[5] CHVÁTAL, VAŠEK: Linear Programming. W. H. Freeman and Company, New
York, 1983.
[6] DAVIS, T. A. und P.-C. YEW: A Nondeterministic Parallel Algorithm for General
Unsymmetric Sparse LU Factorization. SIAM Journal on Matrix Analysis
and Applications, 11:383–402, 1990.
[7] DEUFLHARD, P. und A. HOHMANN: Numerische Mathematik. de Gruyter,
Berlin, 1991.
[8] DUFF, I. S.: MA28–A Set of FORTRAN Subroutines for Sparse Unsymmetric
Linear Equations. Report R.8730, AERE, London, 1977.
[9] DUFF, I. S., A. M. ERISMAN und J. K. REID: Direct Methods for Sparse
Matrices. Clarendon Press, Oxford, UK, 1986.
93

Literaturverzeichnis
[10] DUFF, I. S., R. G. GRIMES und J. G. LEWIS: User’s Guide for the Harwell-
Boeing Sparse Matrix Test Problems Collection. Technical Report RAL-92-086,
Computing and Information Systems Department, Rutherford Appleton Laboratory,
Didcot, UK, 1992.
[11] FOSTER, IAN: Designing and building parallel programs - concepts and tools
for software engineering. Addison-Wesley Publishing Company, 1995. Online-
Version: http://www.mcs.anl.gov/dbpp.
[12] JEGGLE, HANSGEORG: Numerische Mathematik I für Ingenieure. Skript zur
Vorlesung, Technische Universität Berlin, 1992.
[13] JÁJÁ, JOSEPH: An Introduction to Parallel Algorithms. Addison Wesley, 1992.
[14] MARKOWITZ, H. M.: The Elimination Form of the Inverse and its Application
to Linear Programming. Management Science, 3:255–269, 1957.
[15] MESSAGE PASSING INTERFACE FORUM: MPI: A Message-Passing Interface
Standard, June 1995. Online-Version:
ftp://ftp.mcs.anl.gov/pub/mpi/mpi-1.jun95/mpi-report.ps.
[16] OED, WILFRIED: The Cray Research Massively Parallel Processor System
CRAY T3D. Technical Report, Cray Research GmbH, München, Germany, November
1993.
[17] RAYMOND, ERIC und GUY L. STEELE (Herausgeber): The New Hacker’s Dictionary.
MIT Press, Cambridge, MA, USA, zweite Auflage, 1993. Online-
Version: http://www.ccil.org/jargon/jargon.html.
[18] ROTHBERG, EDWARD: Alternatives for solving sparse triangular systems on
distributed-memory multiprocessors. Parallel Computing, 21:1121–1136, 1995.
[19] SMART, D. und J. WHITE: Reducing the parallel solution time of sparse circuit
matrices using reordered Gaussian elimination and relaxation. In: Proc. IEEE
Internat. Symp. Circuits and Systems, Seiten 627–630, 1988.
[20] STROUSTRUP, B.: The C++ Programming Language. Addison Wesley, zweite
Auflage, Juni 1991.
[21] VAN DER STAPPEN, A. FRANK, ROB H. BISSELING und JOHANNES G. G.
VAN DE VORST: Parallel Sparse LU Decomposition on a Mesh Network of
Transputers. SIAM Journal on Matrix Analysis and Applications, 14(3):853–
879, Juli 1993.
94

Literaturverzeichnis
[22] WUNDERLING, ROLAND: Paralleler und Objektorientierter Simplex-
Algorithmus. Technical Report TR 96-09, Konrad-Zuse-Zentrum für Informationstechnik
Berlin, 1996. (to appear).
[23] WUNDERLING, ROLAND, HANS-CHRISTIAN HEGE und MARTIN GRAMMEL:
On the Impact of Communication Latencies on Distributed Sparse LU Factorization.
Preprint SC 93-28, Konrad-Zuse-Zentrum für Informationstechnik Berlin,
December 1993. Online-Version:
ftp://ftp.zib.de/pub/zib-publications/reports/SC-93-28.ps.
[24] YANNAKAKIS, M.: Computing The Minimum Fill-In is NP-Complete. SIAM J.
on Algebraic and Discrete Methods, Seiten 77–79, März 1981.
[25] ZLATEV, ZAHARI: On some pivotal strategies in Gaussian elimination by sparse
technique. SIAM Journal on Numerical Analysis, 17(1):18–30, 1980.
[26] ZLATEV, ZAHARI, JERZY WASNIEWSKI und KJELD SCHAUMBURG: Y12M –
solution of large and sparse systems of linear algebraic equations: documentation
of subroutines, Band 121 der Reihe Lecture Notes in Computer Science.
Springer-Verlag Inc., New York, NY, USA, 1981.
95