Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

30.05.1986

Konzepte und Beispiele paralleler Rechnerarchitekturen (XVI und Schluß):Zusatzrechner erhöhen System-Flexibilität

Ein aufwendiges Computersystem, bestehend aus drei Hosts der IBM-Serie 4300 sowie zehn parallel arbeitenden Zusatzrechnern des Typs Floating-Point-Systems 164, hat sich nach ersten Berichten seiner Benutzer bei der Berechnung bestimmter biochemischer und physikochemischer Problemstellungen bisher als sehr nützlich erwiesen. Die Leistung dieses "vielseitigen, flexiblen und gut zugänglichen Systems" beim Bearbeiten speziell umgewandelter Anwendungsprogramme soll der typischer Supercomputer durchaus gleichkommen.

Frau Dr. Giorgina Corongiu und Dr. John H. Detrich berichten im "IBM-Journal of Research and Development" (Vol. 29, Nr. 4, 1985) ausführlich über das hochinteressante Parallelrechnersystem, mit dem sie unter anderem auch nach einer Antwort auf den im Bereich der Wissenschaft immer weiter steigenden Bedarf an Rechenleistung suchen. Wobei

sie aber speziell nach Lösungen suchen, die schneller, flexibler und vielseitiger sein sollen als herkömmliche Supercomputer vom Cray- oder CDC-Typ; außerdem soll die Lösung nicht allzuviel kosten und möglichst freizügig immer weiter ausbaubar sein.

Hardwarekomplex mit wenigen Arrayprozessoren

Die Autoren des hier referierten Berichts gehen das Thema Parallelrechner primär von der Praxis heran. Es ging ihnen vor allem darum, ihre umfangreichen wissenschaftlichen Anwenderprogramme so schnell und so leicht wie möglich auf eine Parallel-Konfiguration zu übertragen. Deshalb wählten sie auch einen Hardwarekomplex mit relativ wenigen Arrayprozessoren, von denen aber jeder einzelne recht leistungsstark sein sollte. Deshalb wählten sie eine simple, aber erweiterbare Architektur und deshalb entschieden sie sich auch für Systemsoftware, die nur wenig anders ist als jene, die in der gewöhnlichen, sequentiellen Programmierung genutzt wird. Und sie forderten, es solle möglich sein, die Anwendungsprogramme vollständig im vertrauten Fortran zu schreiben.

Die aktuelle Rechnerkonfiguration der beiden Wissenschaftler sieht so aus, daß sieben FPS-Rechner an einer 4381 hängen, während drei weitere über eine Umschalteinheit entweder auch an die 4381 oder aber an eine 4341 gekoppelt werden können. Die Verbindungen übertragen pro Kanal drei MB pro Sekunde; ebenfalls über einen schnellen Kanal hängt außerdem noch eine weitere 4341 an den beiden anderen IBM-Rechnern.

Die beschriebene Konfiguration erlaubt es, entweder alle zehn 164er an die 4381 zu koppeln oder aber, im anderen Extrem, drei 164er zusammen mit einer 4341 als Experimentier- und Programmentwicklungs- und die restliche Gruppierung als Produktionssystem laufen zu lassen. Vielfach, vor allem über die Wochenenden, laufen aber auch zwei Hoste mit je vier Zusatzrechnern und der dritte mit zweien. Beliebige andere Kopplungen werden genutzt, wann immer die Problemstellungen es sinnvoll erscheinen lassen.

Von den IBM-Rechnern verfügen zwei über je 16 MB und einer über acht MB Speicher; von den FPS-Maschinen haben acht Einheiten vier MB, einer acht und einer zehn MB; alle zusammen also 90 MB. Die Plattenspeicherkapazität addiert sich zu etwa 30 Gigabyte und ist zu rund einem Sechstel direkt den Zusatzrechnern zugeordnet.

In der vorliegenden Konfiguration können die Zusatzrechner nur mit ihrem jeweiligen Host, nicht aber direkt untereinander kommunizieren; darin sehen Frau Corongiu und Detrich eine "fühlbare Begrenzung" der Möglichkeiten ihres "lose gekoppelten" Systems. Denn direkte Kommunikationswege zwischen den Zusatzrechnern würden einen "substantiellen Gewinn an Flexibilität und Leistung" bringen, dazu könnte man einen gemeinsamen Bus oder aber einen gemeinsamen Speicher einrichten.

Was für Erfahrungen machen Wissenschaftler nun, übertragen sie berechnungsintensiven Code, der auf sequentiellen Systemen zu langsam laufen würde, auf die neue Parallelmaschinerie? Die beiden Autoren stellen zunächst fest, daß umfangreiche, vorwiegend auf der CPU laufende Berechnungen nahezu alle einige Schleifen umfassen, die sehr oft durchlaufen werden. Und weiter, daß ein großer Teil jenes Codes nach Anpassung an die parallele Hardware tatsächlich parallel abgearbeitet wird.

Nach erfolgter Parallelanpassung sieht ein typisches Programm so aus, daß zunächst ein sequentieller Teil kommt, der sozusagen der Vorbereitung dient, dann ein paralleler zur gleichzeitigen Bearbeitung durch mehrere Zusatzrechner und dann wieder ein sequentieller; der geht dann entweder in einen weiteren parallelen Teil über oder stellt das Ende des Programms dar, in dem die Resultate zusammengestellt und zur Ausgabe vorbereitet werden.

Parallelisierung geschieht vorwiegend manuell

Die Parallelisierung vorhandener Software entsprechend diesem Schema geschieht vorderhand noch manuell, doch wird bereits überlegt, wie wohl zumindest ein Prä-Compiler aussehen müßte, der den Programmierer bei diesen Arbeiten unterstützen könnte.

Das Verteilen von Programmcode und/oder Daten zu Beginn jedes parallelisierten Codeabschnittes auf die Zusatzcomputer und das Einsammeln der Resultate an deren jeweiligem Ende bewirken einen Zusatzaufwand, der im sequentiellen Originalcode natürlich fehlt. Um ihn möglichst gering zu halten, empfiehlt es sich nach Meinung der Autoren, ein Programm unter Umständen sogar eigens umzuschreiben; und zwar mit dem Ziel, möglichst lange parallelcode Blöcke zu erhalten, nicht aber viele kurze.

Eine sorgfältige Analyse der Daten, die zu den Zusatzrechnern gehen beziehungsweise später von ihnen wieder zurückkommen, zeigt in vielen Fällen, daß die Zusatzrechner mit großen Feldern arbeiten, die vom sequentiellen Teil des Programms nie benötigt werden. Auch hier finden sich also recht einfach nutzbare Ansätze zur weiteren Feinabstimmung der Software.

Zwei weitere Feststellungen der Autoren Corongiu und Detrich laufen auf die Aussagen hinaus, ein parallelisiertes Programm laufe erstens um so effizienter, je umfangreicher die parallel durchzuführenden Berechnungen sind, und zweitens, obwohl natürlich schneller, um so weniger effizient, je weiter die Zahl der Zusatzprozessoren bei ein- und demselben Programm gesteigert werde. "Deshalb ist es wichtig, die Zahl der Zusatzrechner je nach Programm variieren zu können - wie unser System das ermöglicht."

Kaum Probleme mit gemischter Software

Bei den hier knapp skizzierten Anwendungen und Versuchen liefen der Host jeweils unter VM/SP und die Zusatzrechner unter ihrer spezifischen Systemsoftware. Damit gab es anscheinend keine Probleme, denn "wir fanden keinen Grund, irgendeinen Teil der Betriebssoftware zu ändern".

VM/SP gilt bekanntlich als Timesharing-System, bei dem Jobs auf virtuellen Maschinen (VMS) laufen, die das System erzeugt und die real vorhandene Rechner simulieren. Die Floating-Point-Standardsoftware wiederum enthält die Einschränkung, daß stets nur ein Zusatzrechner an eine VM angehängt werden kann. Da im Falle des vorliegenden Parallelsystems aber mehr als ein Zusatzrechner benötigt wird, werden intern im Host ein Master und mehrere Slave-VMs erzeugt, die die benötigten Zusatzrechner bedienen. Dabei dient wiederum "VMCF", ein Standardprodukt innerhalb von VM/ SP, dem Zweck, diese VMs miteinander kommunizieren zu lassen.

Allgemein gesehen, besteht eine "parallele Task" des hier beschriebenen Systems nun also aus mehreren Fortran-Programmen, die jeweils auf einer eigenen VM innerhalb des Host-Rechners laufen. Jede von ihnen kontrolliert wiederum einen ganz bestimmten Zusatzrechner, der weiteren Fortran-Code bearbeitet.

Eine der VMs, der erwähnte "Master", bearbeitet jenen Teil des ursprünglichen, sequentiellen Fortran-Codes, der - alles andere steuernd - auf dem Host-Rechner laufen soll. Und daneben noch Hilfsunterprogramme, die die Kommunikation mit den Slave-VMs sowie mit jenem Zusatzrechner, der direkt an die Master-VM gekoppelt ist, steuern.

Die Programme, die von den Slave-VMs abgearbeitet werden, sind bei dieser Aufteilung viel kürzer als die der Master-VM, denn die Slaves sind ja in der Praxis kaum mehr als Übertragungspunkte zwischen der Master-VM einerseits und den Zusatzrechnern, die an den Slaves hängen, andererseits. Die Programme der Slaves bestehen nämlich im wesentlichen nur aus Codeabschnitten zur Abwicklung der Kommunikation mit dem Master sowie aus weiteren Dienstunterprogrammen zur Kommunikation mit dem jeweils zugehörigen Zusatzrechner.

Da bei der hier beschriebenen Konfiguration jedem einzelnen Zusatzprozessor eine eigene Slave-VM als "Host" zugeordnet ist, können die Standard-Dienstprogramme, die Floating Point Systems mit seinen Maschinen ausliefert, jetzt ohne Modifikation zur Kommunikation mit dem "Host" also hier der Slave-VM benutzt werden.

Code für jeden Rechner gleich

Beim parallelen Betrieb der Slaves und der Zusatzrechner ist, wie oben schon angedeutet, der Code, den die Zusatzrechner bearbeiten, für jeden von ihnen der gleiche. Diese Aussage gilt sinngemäß natürlich auch für die Slaves - und es bleibt mithin allein der Master-VM überlassen, die einzelnen Slaves so in der richtigen Weise mit unterschiedlichen Daten zu versorgen, daß letztlich doch verschiedene Teilberechnungen durchgeführt werden.

Der Einsatz von "VMCF" bedingt die teilweise Anwendung von Assembler-Code; in diesem Zusammenhang hat es sich nun als nützlich erwiesen, diesen Code ein für allemal

in Dienstunterprogrammen zusammenzufassen, die dann von den gewöhnlichen Fortran-Programmen benutzt werden. Denn dies "erleichtert den Übergang in den Parallelmodus ganz erheblich", wie man hören kann. Der ganze neue Satz von Dienstprogrammen wurde mit dem Kürzel "VMFACS" bezeichnet, und seine Entwicklung war in der Tat einer der allerersten Schritte beim Implementieren des Parallelsystems; es ist daher umso bemerkenswerter, daß VMFACS hinterher praktisch kaum mehr modifiziert werden mußte.

Die "VMFACS"-Dienstprogramme wurden bewußt so gestaltet, daß die benötigten Funktionen von ihnen - bei hinreichender Flexibilität - auf die einfachste denkbare Art und Weise zur Verfügung gestellt werden. Dabei umfaßt "VMFACS" aber nur Funktionen, die nicht auch durch kurze Fortran-Codesequenzen bereitgestellt werden könnten; und so fehlen in "VMFACS" zum Beispiel auch Hilfen, die das Wiederanlaufen nach einem Fehler erleichtern. Das aber, so sagen die Autoren, sei Absicht; denn man wollte die Fortran-Programmierer damit sogar ermutigen, nach der jeweils besten Strategie zur Überführung von sequentiellem Code in eine parallel ausführbare Form individuell selber zu suchen.

Eine interessante Situation kommt zustande, wenn man jenen Code, der sonst - gleichzeitig - auf den parallelen Zusatzrechnern läuft, in jene Programsabschnitte mit einsetzt die direkt auf der Master- und den ihr zugeordneten Slave-VMs laufen; wenn man also will, daß eine Anwendung auf mehrere VMs verteilt, nur auf dem Host, nicht aber auf den Zusatzrechnern läuft.

So ein Vorgehen ist sinnlos, hat man nur einen einzigen Host mit nur einem einzigen Prozessor; denn dann entstehen ja nur zusätzlicher Verwaltungsaufwand. Doch Hosts mit mehreren CPUs können die einzelnen VMs zum Teil gleichzeitig laufen lassen - und man erzielt, wie Messungen ergeben haben, dann auch tatsächlich eine gewisse Beschleunigung: es wird ja nun eben "hostintern" parallel gearbeitet.

Die praktischen Erfahrungen mit der Übertragung von sequentiellem Code auf die parallele Konfiguration zeigten, schreiben Frau Corongiu und Detrich, daß dies nicht viel schwieriger ist, als Code etwa auf ein anderes sequentielles Rechnersystem von abweichender Architektur zu übertragen. Dabei wird aber vorausgesetzt, daß es sich um Code handelt, der dem Programmierer wohlvertraut ist.

Vergleich der Anwendungen bei den Zusatzprozessoren

Zur Illustration, wie Anwendungsprogramme sich bei Einsatz von einem, drei, sechs und zehn Zusatzprozessoren verhalten und wie lange vergleichsweise eine "Cray-1S" braucht, um sie zu bearbeiten, dienen vier Beispiele. Dabei berechnet das "Integral"-Programm in rascher Folge algebraische Ausdrücke in einer Weise, daß die Berechnung jedes einzelnen Integrals in keiner Weise von irgend einem anderen Integral abhängt. Diese Eigenschaft der Anwendung macht es besonders leicht, sie parallel abzuarbeiten.

Ein Programm namens "SCF" berechnet in iterativen Schritten eine komplizierte molekulare Elektronen-Struktur solange, bis Konvergenz erreicht ist. Dabei gehört zu den Einzelschritten jeder Iteration auch einer (es ist der zeitraubendste), bei dem die Resultate der letzten Iteration zur Berechnung der aktuellen Iteration aufbereitet werden müssen; nur dieser Schritt wird - zur Zeit - im Parallelmodus ausgeführt.

Programme wenig modifiziert

Das dritte Programm heißt "Monte Carlo" und befaßt sich vor allem mit der Ermittlung von Änderungen der potentiellen Energie bei der Bewegung von Molekülen. Und schließlich wird noch ein Programm namens "molecular dynamics" besprochen, das die kinetische Bewegung von Molekülen beschreibt.

Was den Vergleich mit den Rechenzeiten auf der Cray betrifft, ist die Information wichtig, daß die vorhandenen sequentiellen Programme nur insoweit modifiziert wurden, als nötig war, sie Cray-fähig zu machen. Es hat also weder für die Cray noch für die Parallelrechner-Konfiguration eine weitergehende, spezifische Anpassung stattgefunden, solche Anpassungen würden in beiden Fällen gewiß zu weiteren Tempogewinnen führen.

Wie die Tabelle zeigt, laufen die Programme Monte Carlo, Integral und Molecular Dynamics auf einer Konfiguration mit sechs Zusatzrechnern in etwa gleich schnell wie auf einer Cray, während das Programm SCF deutlich länger braucht.

Deutlich zeigen die Zahlen, daß die Effizienz geringer wird, setzt man mehr und mehr Zusatzrechner ein. Denn die Konfiguration mit drei Zusatzrechnern benötigt länger als nur ein Drittel der Rechenzeit, die bei Einsatz nur eines Zusatzprozessors benötigt wird; und bei sechs und zehn Zusatzrechnern sind ähnliche Abweichungen vom theoretischen Idealwert erkennbar. Denn die Monte-Carlo-Rechnung beispielsweise läuft bei zehn Zusatzrechnern in 22 Minuten ab, statt in 16,2.

Aus den bisherigen Resultaten mit dem neuen, flexiblen Parallel-System ziehen die Autoren den bemerkenswerten Schluß, "Parallelismus scheint eine Technik zu sein, die sich in der Physik und in benachbarten Bereichen der Ingenieurwissenschaften auf breiter Front einsetzen läßt". Außerdem wohl auf Gebieten wie zum Beispiel Ökonometrik, Grafik und anderes mehr.

Abschließend betonen die amerikanischen Parallelismus-Forscher neben der Vielseitigkeit ihres Systems - das sich für skalare, für vektorielle und für parallele Probleme gleichermaßen eigne - noch einen anderen wichtigen Aspekt, der bei der Wahl einer bestimmten Rechnerkonfiguration bestimmt oft ins Gewicht fällt: die Zuverlässigkeit. Hier schneidet das beschriebene System gut ab. Denn bei der vorliegenden Konfiguration mit drei Hosts ist es möglich, die Anlage von jedem einzelnen dieser Hosts aus zu betreiben; außerdem dürfte es in höchstem Maße unwahrscheinlich sein, daß jemals alle zehn Zusatzrechner gleichzeitig ausfallen. Es wird also wohl "immer" Teilkonfigurationen geben, die bei Ausfall anderer Komponenten des Gesamtsystems weiter benutzt werden können.

Parallelverarbeitung

Mit diesem Beitrag endet jetzt die Serie zur Parallelverarbeitung, mit der dieses Gebiet beleuchtet werden sollte, ohne daß Systematik oder enzyklopedische Vollständigkeit angestrebt war. Bisher erschienene Beiträge in dieser Reihe in den Ausgaben 20/85 (Seite 58), 22/85 (Seite 56), 25/85 (Seite 76), 28/85 (Seite 18), 36/85 (Seite 26), 38785 (Seite 24), 41/85 (Seite 60), 44/85 (Seite 42), 46/85 (Seite 38), 51/52-85 (Seite 42),5/86 (Seite 65), 10/86 (Seite 26), 12/86 (Seite 39), 15/86 (Seite 53) und 17/86 (Seite 34). Problem Parallelisierung

Der heute vieldiskutierte, schrittweise Übergang von sequentiellen Rechnern auf parallele Architekturen zwingt dazu, sich intensiv mit der Frage der optimalen Parallelisierung von Software zu befassen. Eine Aufgabe, die durchaus nicht immer so relativ glatt von der Hand geht, wie im Hauptbericht beschrieben, und für die man deshalb intensiv nach Möglichkeiten der Automatisierung sucht.

Der Einsatz paralleler Rechner hat oder besser hätte für viele Wissenschaftler grundsätzlich vorteilhafte Aspekte, sagen anerkannte Fachleute wie etwa Kenneth Wilson von der amerikanischen Cornell University in Ithaca, New York. Allerdings müssen die Benutzer der Rechner, wollen sie von den neuen Möglichkeiten profitieren, auch bereit zum Umdenken sein und sich mit parallelen Strukturen gedanklich auseinanderzusetzen. Es reiche wohl kaum, wenn etwa allein nur die Entwickler von Systemsoftware auf die neuen Bahnen einschwenken.

Dem Übergang von sequentieller auf parallele Software steht allgemein entgegen, daß die Art der konkreten Anwendung hierbei eine ganz entscheidende Rolle spielt. Denn bestimmte Aufgaben, etwa aus dem Bereich der Signalverarbeitung oder aus Gebieten, in denen viel mit Vektoren gearbeitet wird, lassen sich relativ leicht in Teilstücke aufspalten, die dann auf getrennten Prozessoren parallel laufen können. Doch andere Programme, etwa aus dem Bereich der sogenannten "Künstlichen Intelligenz", sind weitaus schwerer zu zerlegen. Dies gilt vor allem deshalb, weil die einzelnen Teilberechnungen innerhalb dieser Programme in unvorherbestimmbarer Reihung und Weise ausgeführt werden müssen: das erschwert es sehr, die voraussichtliche Belastung des einzelnen Prozessors zu kalkulieren und für eine halbwegs gleichmäßige Verteilung der Last zu sorgen. Die aber ist Bedingung, soll das Parallelsystem effizient arbeiten.

Zwar kann man die Aufgabe des Parallelisierens in vielen Fällen manuell und teilweise sogar automatisch einigermaßen befriedigend lösen: doch es gibt Programme, deren Verhalten von Haus aus unvorhersagbar ist. Für die müßte deshalb praktisch eine Form der automatischen dynamischen Lastverteilung während der Laufzeit entwickelt werden, sagte ein Mitarbeiter Wilsons unlängst dem US-Elektronikerfachblatt "Elektronics".

Ein Programm zu parallelisieren ist ein Unterfangen, das wohl am besten ganz am Anfang eines Projektes steht: nämlich schon während des ,,Entwurfs". Schon in dieser ersten von drei Phasen, in die man die Entwicklung einer Anwendung bekanntlich gliedern kann, sollte also systematisch nach Programmteilen gesucht werden, die sich für die Aufspaltung in parallele Blöcke eignen. So hat der Compiler dann in Phase zwei also während der "Implementierung", bereits "vorgekaute Bissen" und kann sich auf die Detalls der Übersetzung in Code für die Hardware konzentrieren. Für die dritte Phase, das "Tuning", benötigt der Entwickler einer Anwendung Werkzeuge, die ihm erlauben, das tatsächliche Laufverhalten des Programms zu beobachten und dabei auch jene asynchronen Ereignisse wie beispielsweise Ein- und Ausgaben zu verfolgen, deren Zeitverhalten während der anfänglichen Analyse noch nicht vorhersehbar war. Denn diese Ereignisse können das Zeitverhalten eines ganzen Programms später entscheidend modifizieren.

An Werkzeugen dieser Art und an ähnlichen zur Unterstützung der Benutzer von herkömmlichen Vektorrechnern, wird derzeit in vielen Unternehmen gearbeitet. Außerdem befinden sich Tools wie etwa Prä-Prozessoren für vorhandene Compiler in Entwicklung, die eine möglichst feinkörnige, also sehr kleine Programmteilabschnitte erzeugende Parallelzerlegung von Software bewerkstelligen sollen. Allerdings meinen kritische Stimmen in diesem Zusammenhang, reines Entwickeln solcher Tools allein werde wohl nicht weiterführen können; denn auf diesem Felde seien "echte Erfindungen" nötig, soll das Tor zu einer neuen Zukunft aufgestoßen werden. Heute wisse man nämlich einfach noch nicht, wie man effizient arbeitende Werkzeuge zur Erstellung guter paralleler Programme bauen könnte.

Während das Problem der Parallelisierung von Programmen im allgemeinen als reine Softwaresache behandelt wird, gibt es auch Fachleute, die es leider von der Hardware her gelöst sehen wollen. Diese Ideen zirkulieren um die Grundvorstellung, Probleme wie etwa die teilweise unzulängliche Synchronisation der Prozessoren und deren zeitweise unbefriedigende Auslastung seien im Grunde uralte Bekannte in der Welt der elektronischen Rechenanlagen und es sei doch wohl besser, für sie zunächst effiziente und innovative Hardwarelösungen zu suchen: dann erst solle man sich mit der Entwicklung von Software befassen, die diese neuen Hardwaremechanismen optimal nütze.

Auf dem Weg zu leistungsstarken und außerdem bequem handhabbaren Parallelrechnern scheint also noch manche Engstelle zu liegen. Doch eines ist heute schon klar: das Entwickeln paralleler Software ist eine herausfordernde Aufgabe, der sich im Laufe der Zeit gewiß kein Programmierer entziehen können wird, denn die allgemeine Richtung, in die der Zug fährt, liegt längst fest.

Klar ist auch, daß die Entwicklung paralleler Programme vielleicht mühevoll ist, aber letztlich gewiß kein unlösbares Problem darstellt. Kenner der Szene kritisieren in diesem Zusammenhang allerdings, daß Experten über die immensen Schwierigkeiten der parallelen Programmierung zwar vielfach laut Klage führen - doch seien das meist genau jene, die einfach die Mühen des ständigen Neuhinzulernens scheuten; Mühen, die aber unvermeidbar seien, wolle man nicht ewig auf dem heutigen Stand verharren. es