Parallelrechner leiden derzeit noch an einer Kinderkrankheit: dem Mangel an Software. Während für die Vektorisierung großer Rechenprobleme eine Reihe von Standardlösungen existiert, ist die Parallelisierung solcher Aufgaben noch nicht wesentlich über das Forschungsstadium hinausgekommen. Der Autor des folgenden Beitrags läßt seine Erfahrungen aus einer Mitwirkung am Suprenum-Projekt einfließen.

Die Supercomputer-Entwicklung der letzten zehn Jahre ist geprägt durch die Vektorrechner, deren Zahl insbesondere in den letzten zwei Jahren sowohl in der Bundesrepublik als auch weltweit enorm gestiegen ist. Obwohl unter ihnen schon Multiprozessoren (Parallelrechner) sind, zum Beispiel die Cray X-MP oder Cray 2, werden sie in der Praxis vorwiegend als uniprozessorale Number-Cruncher eingesetzt, das heißt, jeder Prozessor arbeitet seinen eigenen Programmstapel ab.

Effizienz nimmt mit Prozessorzahl ab

Wenn man diese Rechner auch als Parallelrechner bezeichnet, so denkt man dabei an einen Prozessoreinsatz in der Weise, daß alle Prozessoren zugleich (parallel) an der Ausführung eines einzigen Programms arbeiten. Dadurch kann die Rechenzeit im Vergleich zu einem Uniprozessorlauf reduziert werden. Beim Einsatz von p parallel an einem Programm arbeitenden Prozessoren ist eine Beschleunigung im besten Falle um den Faktor p möglich. Praktische Beispiele größeren Umfangs beweisen, daß zum Beispiel ein Beschleunigungsfaktor von rund 3,6 beim Einsatz von vier Prozessoren bei bestimmten Anwendungen erreichbar ist. Dies entspricht einer Effizienz von 90 Prozent. Wissenschaftlich umstritten ist, ob so hohe Effizienzen auch auf Parallelrechnern mit einigen hundert oder tausend Prozessoren erzielbar sind.

Bei der Entwicklung paralleler Rechner kann man heute zwei unterschiedliche Ansätze beobachten. Einerseits gibt es schon auf dem Markt befindliche Parallelrechner, die aus wenigen (2 bis 8) sehr leistungsfähigen Prozessoren (meist Vektorprozessoren) mit mindestens je 100 Megaflops bestehen, andererseits werden Parallelrechner entwickelt oder sind schon auf dem Markt, die eine größere Zahl von (Mikro-)Prozessoren besitzen (auf dem Markt bis zu 128, in der Entwicklung bis zu 1024 und darüber hinaus), deren Leistung pro Prozessor bei etwa 1 bis 10 Megaflops liegt.

Während man beim ersten Ansatz versucht, die Prozessorzahl zu steigern (wie bei dem kürzlich von der Firma Cray Research gestoppten MP-Projekt, das unter der Leitung von Steve Chen stand), erhöht man beim zweiten Ansatz die Leistung der Prozessoren dadurch, daß man zum Beispiel Skalar- und Vektorprozessoren ersetzt beziehungsweise ergänzt (zum Beispiel beim Intel iPSC). Beide Ansätze verfolgen dasselbe Ziel: die Entwicklung von Parallelrechnern, die aus einer großen Zahl sehr leistungsfähiger Prozessoren bestehen, um "Superprobleme" in angemessener Zeit lösen zu können. Dies ist nur möglich, wenn die Maschinen Leistungen im Gigaflop-Bereich oder mehr bieten. Dieses Ziel zu erreichen, dient der Realisierung und Erforschung einer Vielzahl von Parallelarchitekturen.

Welches sind nun die Probleme, mit denen ein Benutzer beim Übergang von einem konventionellen Rechner (Uniprozessor) zu einem Parallelrechner konfrontiert wird? Zunächst einmal ist Parallelisierung etwas prinzipiell anderes als Vektorisierung. Während die Vektorisierung eines Programms im wesentlichen auf Schleifenebene abläuft, geht eine Parallelisierung erheblich tiefer. Sie verlangt eine Zerlegung des Problems in Teilaufgaben und damit eine starke Umstrukturierung des konventionellen Programms. (Häufig tritt das Vektorisierungsproblem als Teilproblem der Parallelisierung auf, zum Beispiel wenn der Parallelrechner ein Multi-Vektorprozessor ist.) Kurzum, Parallelisierung hat eine andere Qualität als Vektorisierung.

Ein sehr wichtiger Aspekt einer effizienten Parallelisierung besteht in der gleichmäßigen Lastverteilung auf die parallel arbeitenden Prozessoren. Da das Endergebnis erst dann vorliegt, wenn jeder Prozessor seine Teilaufgabe beendet hat, ist bei der Aufgabenverteilung darauf zu achten, daß jeder Prozessor jederzeit beschäftigt ist, seine Zeit also optimal nutzt.

Eine Parallelisierung hat beim heutigen Stand der Technik "per Hand" zu erfolgen. Es gibt im Augenblick noch keine Software-Unterstützung, die eine automatische Umstellung vom konventionellen zum Parallelprogramm ermöglicht, wie dies bei der Vektorisierung durch Vektorsierer (interaktiv oder nicht) heute in einem zufriedenstellenden Maße gegeben ist.

Die Parallelisierung hat in bezug auf den Zielrechner zu erfolgen. Ist der Parallelrechner ein Rechner mit "shared memory" oder "local memory", oder hat er beides? Von der Beantwortung dieser Frage hängt die zu wählende Parallelisierungsstrategie in entscheidendem Maße ab. Andere wichtige Parameter in diesem Zusammenhang sind:

- die Problemgröße, die in Angriff genommen werden soll;

- die lokale Speichergröße (bei Local-Memory-Rechnern);

- die Synchronisationszeit (bei Shared-Memory-Rechnern);

- die Anzahl der Prozessoren, die zur Problemlösung eingesetzt werden soll oder kann;

- das Verhältnis von Kommunikations- und Rechengeschwindigkeit (bei Local-Memory-Rechnern).

Völlig neu ist für den Benutzer das Synchronisationsproblem auf Shared-Memory-Rechnern beziehungsweise das Kommunikationsproblem bei Local-Memory-Rechnern. Das parallele Denken in diesen Strukturen ist in der Regel gewöhnungsbedürftig und muß erst erlernt werden. Programmierfehler in diesem Bereich erschweren das "Debuggen" von Programmen teilweise erheblich, da sie zu Laufzeitfehlern führen, die nicht immer reproduzierbar sind. So ist es etwa möglich, die Kommunikation zwischen Prozessoren so unsauber zu organisieren, daß Verklemmungen (Dead-Locks) bei einem Lauf auftreten, bei einem Wiederholungslauf (mit gleichen Daten) eventuell jedoch nicht. Diese Umstände können zu sehr langen Programmentwicklungszyklen auf Parallelrechnern führen.

Was ist der heutige Stand der Technik beziehungsweise der Wissenschaft im Bereich Parallelverarbeitung? Die Vektorisierung ist forschungsmäßig abgehakt. Man kennt heute eine Fülle von Vektorisierungstechniken sowohl auf algorithmisch-numerischer als auch auf Compiler-Ebene. Die Parallelverarbeitung dagegen ist heute ein Forschungsthema ersten Ranges. Die Anzahl der Veröffentlichungen und Tagungen auf diesem Gebiet hat in der letzten Zeit sprunghaft zugenommen; dies beweist beispielsweise ein Blick in die internationale Zeitschrift "Parallel Computing".

Einige grundsätzliche Probleme, die insbesondere aus Anwendersicht der Lösung harren, seien kurz aufgezählt: Bei der Fülle der verschiedenen Parallelrechnerarchitekturen, die entwickelt und untersucht werden, ist nicht zu erkennen, wie das schon oben angesprochene Problem der Programmportabilität zwischen konventionellem Rechner und Parallelrechner automatisch gelöst werden kann, ganz zu schweigen von dem Portabilitätsproblem innerhalb der unterschiedlichen Architekturen der Parallelrechner selber.

Offene Fragen sind unter anderem auch:

- Was ist mit Parallelrechnern grundsätzlich möglich?

- Welche Problemklasse kann mit welcher Parallelrechnerarchitektur effizient gelöst werden?

- Welches ist die geeignetste Sprache für Parallelrechner, die vom Anwender auch akzeptiert wird?

- Ist es notwendig, daß der Anwender sich der Parallelrechnerarchitektur für seine Programmentwicklung bewußt ist, oder können diese Details von ihm ferngehalten werden?

- Wie löst man das Benchmark-Problem für Parallelrechner?

- Sind Parallelrechner überhaupt ,"Universalrechner", oder bleibt ihr Einsatz auf bestimmte Anwendungen beschränkt?

- Sind die Gebiete, auf denen Vektorrechner bisher erfolgreich eingesetzt wurden, eo ipso auch für Parallelrechner geeignet?

Selbstverständlich lassen Parallelrechner eine höhere Leistung als konventionelle Rechner erwarten aber im Augenblick ist noch offen welche speziellen Architekturen oder Leistungsklassen in den nächsten Jahren realisierbar und am Markt durchsetzbar sind.

Es ist sicher nicht überraschend, wenn auch für den Bereich der Parallelverarbeitung die Aussage zutrifft daß die Software-Entwicklung gegenüber den Fortschritten der Hardware zurückliegt. Im Bereich der Hardware ist die Parallelverarbeitung deshalb so weit fortgeschritten, weil sie insbesondere in den USA durch Regierung und Industrie stark gefördert wird.

Auf der Seite der Software-Entwicklung sieht die Sache bei weitem nicht so günstig aus: Es bedarf eines erheblichen finanziellen Aufwandes um die Basisanwendungen in kommerziellen Bereichen und in bestimmten Forschungsgebieten umzustrukturieren und neu zu schreiben. Für parallele Architekturen ist heute im Bereich der Software-Standards noch keine Lösung in Sicht. So ist das Sprachproblem der Parallelverarbeitung im Bereich der numerischen Anwendungen mit Fortran 77 völlig unzureichend gelöst. So wie der Schritt in die Vektorverarbeitung ohne genügende Sprachunterstützung getan wurde - man ist gerade dabei, mit Fortran 8x Sprachmittel für die Kurzbeschreibung von Feldern (also auch Vektoren) einzuführen (etwa zehn Jahre zu spät!) - , wird auch heute der Schritt in die Parallelverarbeitung im Bereich der numerischen Anwendungen ohne Sprachstandard gemacht. Was zum Beispiel Kommunikation oder Synchronisation anbelangt, bietet Fortran 8x keinerlei Unterstützung; das Problem ist auf Fortran 9y verlagert. Die fehlenden Sprachelemente werden in der Regel von Herstellern durch Unterprogrammaufrufe nachgebildet, um keine Spracherweiterungen einführen zu müssen.

Was das Software-Angebot für die heute auf dem Markt befindlichen Parallelrechner betrifft, so ist es sehr klein. Es gibt vereinzelt Softwarepakete, die für einen bestimmten Parallelrechner angepaßt sind. Doch selbst Grundsoftware wie beispielsweise Linpack (eine Bibliothek aus dem Bereich Numerik) ist nur für Parallelrechner mit "shared memory" verfügbar. Es handelt sich dabei um eine Anpassung der alten Linpack-Grundversion aus den 70er Jahren. An einer Neukonzeption dieser Bibliothek speziell für Parallelrechner wird im Augenblick gearbeitet.

Bei dem deutschen Parallelrechner-Projekt "Suprenum " (SUPerREchner für NUMerische Anwendungen) will man das Problem der nicht oder nur in geringem Maße vorhandenen Software von vornherein umgehen, indem zugleich mit der Hardware auch Software für diesen Rechner entwickelt wird. Hier wird an Anwendungen unter anderem aus dem Bereich der Numerik (Grundsoftware), der Strömungsmechanik und technischen Simulation gearbeitet. Ansätze zur interaktiven automatischen Parallelisierung werden in diesem Zusammenhang ebenfalls verfolgt.

Trotz aller hier kritisch aufgeworfenen Fragen sei folgende Prognose gewagt: Die Überwindung der im Augenblick bestehenden Probleme der Parallelverarbeitung ist sicher möglich, vielleicht sogar wesentlich schneller, als man es sich heute vorstellen kann. Erste aussichtsreiche Lösungsansätze sind schon erkennbar. Die Parallelverarbeitung bietet zudem die einzigartige Chance, numerische Simulationen solchen Umfanges in Angriff nehmen zu können, für die Uniprozessoren - seien sie auch noch so schnell - um einiges zu langsam sind. In diesem Sinne werden die rechentechnischen Grenzen durch die Parallelverarbeitung neu definiert werden.

So wie heute Vektorprozessoren zum Standard der Uniprozessoren werden, so werden im nächsten Jahrzehnt Parallelrechner verstärkt auf den Markt drängen. Vermutlich wird IBM hier mit dem Einstieg bei Steve Chens neugegründeter Firma Supercomputer Systems Inc. neue Impulse setzen und die Entwicklung beschleunigen. Auch ist im gegenwärtigen Stadium eine enge Kooperation zwischen Hochschulen und Industrie notwendig, um die zukünftige Entwicklung in die richtigen Bahnen zu lenken. Die vor kurzem in Berlin gegründete Parallel Computing Society e. V. hat sich zur Aufgabe gemacht, in der Bundesrepublik wie auch weltweit die Parallelverarbeitung in jeder Hinsicht voranzutreiben. Dabei ist die Zusammenarbeit zwischen Industrie und Hochschulen auf diesem Gebiet ein besonderes Anliegen.

So wie sich heute der Vektorrechner vom Exoten zum Alltagsrechner gemausert hat, werden auch Parallelrechner in den 90er Jahren nichts Außergewöhnliches mehr sein. Erstaunt wird man dann eher sein, wenn man auf die Frage "Ist das ein Parallelrechner?" die Anwort bekommt: "Nein, noch nicht."

Dr. Wolfgang Rönsch ist Projektleiter im Bereich der Linearen Algebra für das Suprenum-Vorhaben