Skalierbarkeit auf verschiedenen Rechnersystemen

Zur Untersuchung des Skalierbarkeitsverhaltens auf realen Rechnersystemen wurden Laufzeitexperimente auf mehreren Parallelrechnern mit unterschiedlicher Architektur durchgeführt.

Clustersysteme aus Standardkomponenten

Mit Hilfe von Standardkomponenten lassen sich preiswerte Parallelrechner, sogenannte Clustersysteme, aufbauen, in dem man Rechenknoten, basierend auf handelsüblicher Hardware, d. h. CPUs, Mainboards, Speicherbausteinen und Festplatten, wie sie auch in Workstations und kleineren Servern eingesetzt werden, über ein Netzwerk miteinander verbindet. Abhängig vom Budget des Käufers können solche Systeme eine große Prozessoranzahl und eine hohe theoretische Rechenleistung erreichen. Problematisch ist jedoch oft

3.3 Parallelrechner mit verteiltem Adreßraum 105 Prozessor- DOPRI5(4), DOPRI8(7), DOPRI5(4),

anzahl N=896,H=0, 5 N=896,H=0, 5 N=384,H=4, 0

1 1141 1936 316

2 2412 3321 667

4 1285

Tab. 3.2:Programmlaufzeit in Sekunden für die Implementierung (D) für verteilten Adreßraum gemessen für das Test-problem BRUSS2D-MIX auf dem Clustersystem CLiC.

die Geschwindigkeit des Verbindungsnetzwerks, da preiswerte Standardhardware zur Realisierung von Netzwerken (z. B. auf Basis von Fast Ethernet oder Gigabit Ethernet) oft eine zu geringe Übertragungs-bandbreite und zu große Latenzzeiten im Verhältnis zur Arbeitsgeschwindigkeit der Prozessoren besitzen.

Dieser Effekt wird oft noch durch aufwendige Softwareprotokolle verstärkt. Aber auch Verbindungsnetz-werke, die speziell für den Einsatz in Clustersystemen konzipiert wurden (z. B. Myrinet, Infiniband und Quadrics), bieten im Verhältnis zur CPU-Geschwindigkeit oft keine ausreichend hohe Geschwindigkeit für feingranulare Anwendungen.

CLiC. Der Chemnitzer Linux Cluster (CLiC), der im Jahr 2000 an der TU Chemnitz in Betrieb genommen wurde, ist ein Clustersystem, bestehend aus 528 Knoten, die durch ein Fast-Ethernet-Netzwerk mit einer Übertragungsbandbreite von 100 MBit/s verbunden sind. Die Knoten sind jeweils mit einem mit 800 MHz getakteten Pentium-III-Prozessor ausgestattet. Tabelle3.2zeigt einige Beispiele für Laufzeiten, die unter Verwendung von 1, 2 oder 4 Knoten für Implementierung (D) für das Testproblem BRUSS2D-MIX gemes-sen wurden. Dabei wurde die MPI-Bibliothek LAM/MPI 6.3.2 verwendet. Wie diese Meßergebnisse zeigen, kann auf diesem System durch die parallele Ausführung der Implementierung (D) trotz hoher Problemgrö-ße kein Laufzeitgewinn erzielt werden. Ursache sind die sehr hohen Laufzeiten der globalen Kommunika-tionsoperationen, die bei einer weiteren Erhöhung der Prozessoranzahl noch vergrößert würden.

Opteron-SMP-Cluster. Heutige Clustersysteme bestehen oft aus sogenannten SMP-Knoten. SMPsteht für englisch:symmetric multiprocessing. Mit diesem Begriff werden Rechnerarchitekturen mit gemeinsamem Adreßraum bezeichnet, deren Prozessoren alle die gleiche Funktionalität bieten und die gleiche Sicht auf das Rechnersystem besitzen. Zur Zeit werden bei der Anschaffung von Clustersystemen häufig SMP-Kno-ten mit 2 oder 4 Prozessorkernen bevorzugt, da diese momentan ein günstigeres Preis-Leistungs-Verhältnis bieten als Ein-Prozessor-Knoten. Der besondere Vorteil der Verwendung von SMP-Knoten besteht darin, daß für die Kommunikation zwischen Prozessoren innerhalb eines Knotens der im Vergleich zur Netz-werkgeschwindigkeit schnelle gemeinsame Speicher genutzt werden kann. Für die Untersuchung der par-allelen Implementierungen eingebetteter RunKutta-Verfahren wurde auch ein solcher SMP-Cluster ge-nutzt. Dieses vom Lehrstuhl für Angewandte Informatik 2 der Universität Bayreuth seit 2004 betriebene System besitzt 32 Knoten mit je zwei Prozessoren vom Typ AMD Opteron DP 246 mit einer Taktfrequenz von 2 GHz. Die Knoten können über drei unterschiedliche, voneinander unabhängige Netzwerke mitein-ander kommunizieren. Dabei handelt es sich um ein Fast-Ethernet-Netzwerk mit 100 MBit/s, ein Gigabit-Ethernet-Netzwerk mit 1 GBit/s und ein Infiniband-Netzwerk mit 10 GBit/s. Die unterschiedlichen Ge-schwindigkeiten der Netzwerke erlauben es, den Einfluß der Netzwerkgeschwindigkeit auf die Laufzeit paralleler Programme zu untersuchen.

Abbildung3.4zeigt einige der auf diesem System für die Implementierungen (A) und (D) für das Test-problem BRUSS2D-MIX gemessenen Speedup-Werte. Zum Vergleich wurden dabei die drei unterschiedlich schnellen Verbindungsnetzwerke sowie zwei verschiedene MPI-Implementierungen herangezogen. Die Er-gebnisse zeigen deutlich, daß die Programmlaufzeit durch die Laufzeit der Kommunikationsoperationen bestimmt wird. Dies ist vor allem daran erkennbar, daß sich für unterschiedliche Netzwerkgeschwindig-keiten und unterschiedliche MPI-Implementierungen der beobachtete Speedup stark verändert, während die beiden Implementierungen (A) und (D) trotz unterschiedlicher Lokalitätseigenschaften nahezu gleiche Speedups erreichen. Im Vergleich zum älteren CLiC-System verbessert sich die Skalierbarkeit auf diesem System nur geringfügig. Zwar kann für beide MPI-Implementierungen und für alle Verbindungsnetzwerke ein Speedup größer als 1 erreicht werden, wenn nur zwei Prozesse auf ein und demselben Knoten

gestar-(a)

Abb. 3.4: Speedups der Implementierungen (A) und (D) für verteilten Adreßraum gemessen für das Testproblem BRUSS2D-MIX mit dem Verfahren DOPRI5(4), N = 1000 und H = 4, 0 auf einem Opteron-SMP-Cluster für zwei verschiedene MPI-Implementierungen:(a)LAM/MPI 7.1.1,(b)MPICH 1.2.5.

tet werden, sobald jedoch Kommunikation zwischen mehreren Knoten erforderlich ist, verschlechtert sich die Laufzeit in den meisten Fällen. Bei Verwendung von LAM/MPI 7.1.1 konnte für keines der drei Ver-bindungsnetzwerke eine Laufzeitverbesserung durch die Benutzung von zwei oder mehr Knoten erreicht werden. Nur für MPICH 1.2.5 konnte eine Laufzeitverbesserung durch die Verwendung mehrerer Knoten bei Verwendung des Infiniband-Netzwerkes beobachtet werden. Allerdings wächst auch in diesem Fall der Speedup nur bis zu einem Wert von ca. 1.7 bei Verwendung von 16 Knoten an und stagniert danach.

Cray T3E

Bessere Speedups können auf speziell entworfenen, eng gekoppelten Parallelrechnern erzielt werden, deren Verbindungsnetzwerk schnell und mit geringem Overhead arbeitet und auf die verwendeten Prozessoren abgestimmt ist. Beispielsweise wurden auf einem Parallelrechner vom Typ Cray T3E-1200, der von 1997 bis 2004 am Forschungszentrum Jülich betrieben wurde, in den durchgeführten Experimenten mit der Imple-mentierung (D) und dem Testproblem BRUSS2D-MIX Speedups bis zu 17,7 gemessen (siehe Abb.3.5). Die Cray T3E war mit 512 Prozessoren vom Typ DEC Alpha 21164 mit einer Taktfrequenz von 600 MHz ausge-stattet, die durch ein 3D-Torus-Netzwerk mit einer Übertragungsgeschwindigkeit von 500 MB/s verbun-den waren. Der Speicher war physikalisch verteilt organisiert, wurde jedoch zu einem globalen Adreßraum zusammengefaßt. Der Datenaustausch zwischen den Prozessoren erfolgte durch Remote-Speicherzugriffe mittels spezieller Operationen über sogenannte E-Register.

Im Vergleich zu den zuvor betrachteten Clustersystemen und teilweise auch im Vergleich zu moder-neren Parallelrechnern mit gemeinsamem Speicher erreichte die untersuchte Implementierung (D) auf der Cray T3E die beste Skalierbarkeit. Der Grund dafür ist das mit 500 MB/s im Vergleich zum Prozessortakt von 600 MHz sehr schnelle Verbindungsnetzwerk. Zum Vergleich: Das Infiniband-Netzwerk des Opteron-Clusters erreicht eine Übertragungsgeschwindigkeit von ca. 800 MB/s und ist damit nur ungefähr 1,6-mal schneller. Die Opteron-Prozessoren sind mit 2 GHz jedoch 3¹/3-mal höher getaktet als die Alpha-Prozesso-ren der T3E und können pro Takt mehr Daten verarbeiten. Dennoch ist es nicht möglich, alle ProzessoAlpha-Prozesso-ren der T3E effizient auszunutzen. Denn abhängig von der Problemgröße und der Stufenzahl sinkt der Speed-up, wenn eine bestimmte Anzahl von Prozessoren überschritten wird. In den durchgeführten Experimenten konnten ca. 32 bis 48 Prozessoren effizient genutzt werden. Der höchste Speedup für BRUSS2D-MIX von 17,7 wurde mitN = 896 undH= 0, 5 für das 13-stufige Verfahren DOPRI8(7) unter Verwendung von 32 Prozessoren gemessen, was einer parallelen Effizienz von 0,55 entspricht. In Experimenten mit geringerer Problemgröße und/oder geringerer Stufenzahl wurde der maximale Speedup ebenfalls für 32 Prozessoren erreicht, er betrug jedoch nur 12,2 bzw. 14,2.

3.3 Parallelrechner mit verteiltem Adreßraum 107

0 10 20 30 40 50 60 70

0 2 4 6 8 10 12 14 16 18 20

Prozessoranzahl

Speedup

DOPRI5(4), N=896, H=0,5 DOPRI8(7), N=896, H=0,5 DOPRI5(4), N=384, H=4,0

Abb. 3.5:Speedups der Implementierung (D) für verteilten Adreßraum gemessen für das Testproblem BRUSS2D-MIX auf einer Cray T3E-1200.

Parallelrechner mit gemeinsamem Adreßraum

Auch auf Parallelrechnern mit gemeinsamem Adreßraum kann MPI zur Kommunikation zwischen Pro-zessen genutzt werden. Für solche Systeme optimierte MPI-Implementierungen können den gemeinsamen physikalischen Adreßraum zum Nachrichtenaustausch zwischen den Prozessen effizient ausnutzen, indem die Nachrichten direkt in den virtuellen Adreßraum des empfangenden Prozesses kopiert werden, ohne daß Schichten eines Netzwerkprotokolls durchlaufen oder spezielle Remote-Speicherzugriffsoperationen auf Softwareebene ausgeführt werden müssen.

Sun Fire 6800. Eine Untersuchung des Skalierbarkeitsverhaltens der eingebetteten Runge-Kutta-Verfah-ren wurde deshalb auch auf zwei SMP-Systemen, u. a. auf einer Sun Fire 6800, die seit 2001 an der Martin-Luther-Universität Halle-Wittenberg betrieben wird, durchgeführt. Diese Maschine ist mit 24 UltraSPARC-III-Cu-Prozessoren mit einer Taktfrequenz von 900 MHz und einem 8 MB großen L2-Cache ausgestattet.

Aufgrund einer hohen Nachfrage nach Rechenzeit auf dieser Maschine durch andere Nutzer konnten zur Durchführung der Experimente jedoch nur bis zu 8 Prozessoren genutzt werden.

Die für die Implementierungen (A) und (D) für das Testproblem BRUSS2D-MIX mit dem Verfahren DOPRI5(4) gemessenen Speedup-Werte sind in Abb.3.6dargestellt. Für die betrachteten Prozessorzahlen wurden ähnlich gute Speedup-Werte wie auf der Cray T3E gemessen. Im Unterschied zur T3E spielen hier jedoch die Lokalitätseigenschaften eine größere Rolle. FürN =250 beträgt der Speicherbedarf pro Vektor 977 KB. Das bedeutet, daß 8 vollständige Vektoren im 8 MB großen L2-Cache zwischengespeichert werden können. Da sich die Arbeitsmengen bei Erhöhung der Prozessorzahl durch die Aufteilung der Vektoren ver-kleinern, kann bereits bei Verwendung von zwei Prozessoren die gesamte Arbeitsmenge eines Zeitschrittes im L2-Cache zwischengespeichert werden. Daher ist auch mehr als eine Verdopplung des Speedups von 0,86 auf 1,82 für Implementierung (A) und von 0,87 auf 1,77 für Implementierung (D) möglich. Jedoch ver-hindert der hohe Overhead, der durch die Ausführung der Kommunikationsoperationen entsteht, daß der Speedup, bezogen auf die Laufzeit der schnellsten sequentiellen Implementierung, den Idealwert erreicht.

Beim Übergang von zwei auf vier Prozessoren ist dagegen keine Verdopplung des Speedups mehr möglich, da sich bereits bei Verwendung von zwei Prozessoren alle innerhalb eines Zeitschrittes zugegriffenen Daten im Cache befinden, der Kommunikationsoverhead durch die Verwendung zusätzlicher Prozessoren jedoch steigt. Bei weiterer Erhöhung der Prozessorzahl sinkt die Effizienz weiter bis auf einen Wert von 0,58 bei

1 2 3 4 5 6 7 8

Abb. 3.6:Speedups der Implementierungen (A) und (D) für verteilten Adreßraum gemessen für das Testproblem BRUSS2D-MIX mit dem Verfahren DOPRI5(4) und H = 4, 0 auf einer Sun Fire 6800.

0 5 10 15 20 25 30 35

Abb. 3.7:Speedups der Implementierungen (A) und (D) für verteilten Adreßraum gemessen für das Testproblem BRUSS2D-MIX mit dem Verfahren DOPRI5(4) und H = 4, 0 auf einem Knoten des Supercomputers JUMP.

einem Speedup von 4,61 für Implementierung (A) und bis auf einen Wert von 0,55 bei einem Speedup von 4,43 für Implementierung (D) bei Verwendung von 8 Prozessoren. Implementierung (A) erreicht aufgrund der besseren Ausnutzung der räumlichen Lokalität bereits ab zwei Prozessoren eine bessere Laufzeit als Implementierung (D) und baut diesen Vorsprung mit zunehmender Prozessorzahl aus.

FürN = 750 belegt ein vollständiger Vektor rund 8,6 MB. Infolgedessen kann die Arbeitsmenge eines Zeitschrittes auch bei einer Aufteilung auf 8 Prozessoren nicht vollständig im L2-Cache gespeichert wer-den. Der Anteil der im Cache zwischengespeicherten Daten an der Arbeitsmenge eines Zeitschrittes nimmt jedoch mit steigender Prozessorzahl zu. Durch diese Verbesserung der Speicherzugriffslokalität wird der mit wachsender Prozessorzahl steigende Kommunikationsoverhead kompensiert, woraus sich ein etwa li-near steigender Verlauf der Speedup-Kurve für die betrachteten Prozessorzahlen ergibt. Für 8 Prozessoren wurde ein Speedup von 6,51 für Implementierung (A) und ein Speedup von 6,64 für Implementierung (D) gemessen, was einer Effizienz von 0,81 bzw. 0,83 entspricht. Bei genauerer Betrachtung der Effizienz stellt man fest, daß diese für Implementierung (D), die für alle Prozessorzahlen eine geringere Laufzeit er-reicht als Implementierung (A), mit wachsender Prozessorzahl generell geringfügig abfällt, während sie für Implementierung (A) bis zu einer Anzahl von vier Prozessoren ansteigt und erst danach abfällt. Dieser Ef-fekt wird durch das Lokalitätsverhalten der Implementierungen hervorgerufen, da aufgrund der Tatsache, daß nicht die gesamte Arbeitsmenge eines Zeitschrittes im Cache gespeichert werden kann, die zeitliche Lokalität von großer Bedeutung ist, sie mit zunehmender Prozessoranzahl und sinkender Größe der Ar-beitsmengen jedoch gegenüber der räumlichen Lokalität an Einfluß verliert.

JUMP. Der „Jülicher Multiprozessor“ (JUMP) wird seit 2003 am Forschungszentrum Jülich betrieben und war nach Installation der letzten Ausbaustufe Anfang 2004 für einige Zeit Europas schnellster Supercom-puter. Das Gesamtsystem besteht aus 41 IBM-p690-Servern mit je 32 Power4+-Prozessorkernen mit einer Taktfrequenz von 1,7 GHz. Innerhalb der SMP-Knoten können die Prozessoren über einen gemeinsamen Adreßraum kommunizieren. Die Verbindung zwischen den Knoten wird über einen sogenannten High-Per-formance-Switch hergestellt. Bei der Untersuchung der parallelen Implementierungen eingebetteter Runge-Kutta-Verfahren zeigte sich bereits bei Verwendung eines einzelnen Knotens, wobei die gestarteten Prozes-se über den schnellen gemeinsamen Speicher kommunizieren konnten, daß keine gute Skalierbarkeit auf diesem System erreicht werden kann (siehe Abb.3.7). Die Untersuchung wurde deshalb nicht auf mehrere Knoten ausgedehnt, da die dann notwendige Kommunikation über das langsamere externe Verbindungs-netzwerk zu einer weiteren Verschlechterung von Laufzeit und Speedup führen würde.

3.3 Parallelrechner mit verteiltem Adreßraum 109 Abbildung3.7zeigt Speedup-Werte, die für die Implementierungen (A) und (D) bei Verwendung des Testproblems BRUSS2D-MIX für die Problemgrößen N = 250, N = 750 und N = 1000 gemessen wur-den. Für die kleinste untersuchte Problemgröße, N = 250, erreichen beide Implementierungen, (A) und (D), ihren maximalen Speedup von 3,47 bzw. 3,10 bei Verwendung von 16 Prozessoren. Bei Steigerung der Prozessorzahl bis auf 32 fällt der Speedup auf 0,85 bzw. 1,33 ab. Implementierung (A) ist bei Verwendung von N = 250 für Prozessorzahlen bis zu 24 erkennbar schneller als Implementierung (D). Nur wenn 32 Prozessoren benutzt werden, erreicht Implementierung (D) einen höheren Speedup. Für größere Probleme, d. h. fürN = 750 und N = 1000, sind die Unterschiede zwischen den beiden Implementierungen weni-ger deutlich und liegen im Bereich des auf dieser Maschine auftretenden Meßfehlers. FürN=750 beträgt der maximale Speedup der Implementierungen (A) und (D) 3,29 bzw. 3,24. Er wird wie für N = 250 bei Verwendung von 16 Prozessoren erreicht. Bei Verwendung zusätzlicher Prozessoren fällt der Speedup im Vergleich zu N = 250 langsamer ab, und beide Implementierungen erreichen für 32 Prozessoren einen Speedup von 1,92. FürN =1000 erreichen beide Implementierungen ihren maximalen Speedup von 3,35 bzw. 3,53 bereits bei Verwendung von 8 Prozessoren. Im Vergleich zuN= 750 fällt der Speedup bei einer Vergrößerung der Prozessorzahl wiederum langsamer ab. Werden 32 Prozessoren verwendet, erreicht Im-plementierung (A) für N = 1000 einen Speedup von 2,71 und Implementierung (D) einen Speedup von 2,76.

Insgesamt betrachtet, werden für keine der untersuchten Problemgrößen so hohe Speedup-Werte er-reicht, wie dies auf der Sun Fire 6800 der Fall war. Da sich die Laufzeiten der beiden Implementierungen insbesondere für Probleme mit großer Systemdimension aufgrund der relativ geringen Differenz und der wechselnden Reihenfolge nicht eindeutig vergleichen lassen, ist anzunehmen, daß die Laufzeiten wesent-lich durch die Ausführung der Kommunikationsoperationen bestimmt werden und daß der Einfluß der Lokalität mit wachsender Systemgröße sinkt. Dafür spricht auch die Tatsache, daß sich die Skalierbarkeit durch Erhöhung der Problemgröße nicht wesentlich verbessert.

3.3.5 Zusammenfassung

Parallelrechner mit verteiltem Adreßraum sind weit verbreitet, da sich diese Speicherarchitektur sowohl zur Realisierung preiswerter Clustersysteme aus Standardkomponenten als auch zum Aufbau der welt-weit schnellsten Supercomputer eignet. Aufgrund des verteilten Adreßraumes erfolgt die Kommunikation zwischen den Prozessoren eines solchen Rechnersystems durch den Austausch von Nachrichten. Eine stan-dardisierte Programmierschnittstelle für diese Art der Kommunikation ist z. B. MPI.

Die Ausnutzung der Parallelität bezüglich des Differentialgleichungssystems bei der Implementierung eingebetteter Runge-Kutta-Verfahren erfordert in jeder Stufe einen Austausch des Argumentvektors mit Hilfe einer Multibroadcastoperation, wie z. B.MPI_Allgather(). Zur Bestimmung des globalen Maxi-mums des Fehlervektors kann eine spezielle Form einer Multiakkumulationsoperation benutzt werden, wie sieMPI_Allreduce()realisiert. Die Verwendung einer blockweisen Verteilung ermöglicht eine effi-ziente Übergabe der zu übertragenden Nachrichten an bzw. durch die Kommunikationsoperationen, ohne daß eine zusätzliche Vor- oder Nachbereitung der Daten erforderlich ist.

Eine theoretische Betrachtung des Skalierbarkeitsverhaltens zeigt, daß zwar die pro Prozessor erfor-derliche Berechnungszeit mit wachsender Prozessorzahl sinkt, der Kommunikationsaufwand jedoch unter bestimmten Bedingungen anwachsen kann. Asymptotisch wird der Speedup für wachsende Prozessorzahl durch die Laufzeit der Allreduce-Operation dominiert, da die Nachrichtengröße für die Allgather-Opera-tionen mit wachsender Prozessorzahl geringer wird. Steigt also die Laufzeit der Allreduce-Operation mit wachsender Prozessorzahl an, wie dies für die meisten typischen Verbindungsnetzwerke der Fall ist, strebt der Speedup asymptotisch gegen 0, was auf ein schlechtes Skalierbarkeitsverhalten hinweist. Die theoreti-sche Analyse zeigt jedoch auch, daß die Skalierbarkeit durch Erhöhung der Problemgröße verbessert wer-den kann. Dies gilt insbesondere dann, wenn die Kosten für die Funktionsauswertung einer Komponente des Differentialgleichungssystems mit steigender Problemgröße zunehmen, da in diesem Fall der Einfluß der Kommunikationskosten im Verhältnis zu den Berechnungskosten mit steigender Problemgröße sinkt.

Weiterhin sagt die theoretische Skalierbarkeitsanalyse eine gute Skalierbarkeit für den Fall voraus, daß Pro-zessoranzahl und Problemgröße in gleichem Verhältnis gesteigert werden. Dies entspricht der Situation, daß versucht wird, den aus einer Erhöhung der Problemgröße resultierenden zusätzlichen Parallelitäts-grad durch Verwendung zusätzlicher Prozessoren auszunutzen. Eine besonders gute Skalierbarkeit ergibt

sich in dieser Situation vor allem dann, wenn die Kommunikationsoperationen asymptotisch nicht teurer sind als die Funktionsauswertungskosten.

Das Lokalitätsverhalten der parallelen Implementierungen verbessert sich mit zunehmender Prozessor-zahl, da durch die Aufteilung der zu verarbeitenden Daten die Größe einiger Arbeitsmengen abnimmt.

Dies hat zur Folge, daß die Berechnungszeit schneller als mit dem Reziproken der Prozessorzahl sinkt. Da die Laufzeit für große Prozessorzahlen jedoch durch die Kommunikationskosten dominiert wird, hat das Lokalitätsverhalten in der Regel lediglich für kleine Prozessorzahlen Einfluß auf die Skalierbarkeit.

In Laufzeitexperimenten auf mehreren unterschiedlichen parallelen Rechnersystemen konnten meist nur geringe Speedups erzielt werden. Speziell auf aus Standardkomponenten aufgebauten Clustersyste-men ist es z. T. schwierig, auch nur eine geringe Beschleunigung durch die parallele Ausführung zu errei-chen, da die Kommunikationskosten aufgrund des im Verhältnis zur Prozessorgeschwindigkeit oft lang-samen Netzwerks enorm hoch im Vergleich zur Berechnungszeit sind. Doch auch auf Systemen mit meinsamem Adreßraum, auf denen ein effizienter Nachrichtenaustausch zwischen Prozessen über den ge-meinsamen Adreßraum realisiert werden kann, setzt eine gute Skalierbarkeit voraus, daß bei wachsender Prozessoranzahl die Verbesserung der Lokalitätseigenschaften die steigenden Kommunikationskosten auf-wiegen. Die beste Skalierbarkeit wurde auf einer Cray T3E-1200 beobachtet. Bei diesem System handelt es sich um einen für die Kommunikation mittels Nachrichtenaustausch optimierten Supercomputer, der ein im Vergleich zur Prozessorgeschwindigkeit wesentlich schnelleres Verbindungsnetzwerk besitzt als die betrachteten Clustersysteme.