Daß Computer-Konzepte den unbefangenen Betrachter an Prospekte von LKW-Herstellern erinnern, kommt sicher nicht alle Tage vor - und doch: Ein neues Rechnersystem aus Berlin legt sofort die Assoziation zu jenen bekannten Darstellungen nahe, bei denen ein und derselbe Lastwagen mal als Feuerwehr-, mal als Krankenwagen und mal als Kipper für Kiestransporte erscheint - obwohl es sich doch immer um das gleiche Chassis handelt.
Das "immer gleiche Chassis", mit dem dieser Beitrag sich nun beschäftigen will, wurde in Berlin an der Forschungsstelle für innovative Rechnersysteme und -technologie der Gesellschaft für Mathematik und Datenverarbeitung entwickelt und hört auf den Namen "Unima". Dabei handelt es sich, so erläutern die Autoren Brüning, Giloi, Kallerhoff und Rüsse (im GMD-Spiegel 1/85), um einen "flexiblen Mehrrechner-Architekturrahmen", der die "gemeinsame Grundlage für eine Vielfalt spezieller Systeme" abgeben soll.
Wirtschaftlich durch Standardisierung
Die Frage nach den Vorteilen einer gemeinsamen Grundlage beantworten die Berliner Forscher so - und ähnliches war erst kürzlich auch im Rahmen eines kleinen Kolloquiums zu hören - daß man mit spezialisierten Rechnersystemen die Leistung eines herkömmlichen Universalrechners "um ein Vielfaches übertreffen" könne; doch da in unserer Welt alles am Gelde hängt, darf man die Wirtschaftlichkeit dabei nicht völlig aus den Augen verlieren. Und achtet man auf die Kosten, so zeigt sich eben - wie auch Stimmen aus der Industrie bestätigen - sehr rasch, daß solche Spezialrechner "nur dann auch die kostengünstigere Lösung darstellen", wenn man "sie weitgehend aus standardisierten" - also vergleichsweise billigen -"Hard- und Softwarekomponenten aufgebaut hat. Denn sonst fallen ja hohe zusätzliche Entwicklungskosten für die Komponenten der spezialisierten Lösung an.
Das also ist die tiefere Überlegung hinter der Idee, einen "allgemeinen und flexiblen Architekturrahmen" zu schaffen, der als gemeinsame Grundlage vieler einzelner Spezialsysteme diesen kann - eben die Unima. Wobei diese Unima sich - einerseits - dem Benutzer als Unix-Maschine darstellt, während sie - andererseits - in weiten Grenzen zu einem anwendungsspezifisch gestalteten Mehrrechnersystem erweitert werden kann. Sei es, daß man sich ein leistungsfähiges Mehrprozessor-System zur Entwicklung von Software wünscht, sei es, daß "anwendungsdatentypen-spezifische Ko-Prozessoren" als "Beschleuniger komplexer, anwendungsspezifischer Operationen" gefragt sind oder sei es auch, daß man innovative Rechnerhierarchien aufbauen möchte, bei denen nun die Unima als "Master" fungiert, während unter ihrer Kontrolle besondere Subsysteme mit eigenen Betriebssystemen vor sich hin werkeln.
Um zu verstehen, warum die Berliner GMD-Forscher gerade auf Multi-Mikrocomputersysteme setzen, muß man sich kurz erzählen lassen, was denn eigentlich deren besondere Vorteile sind im Vergleich mit konventionellen "Mainframes". Dann erfährt man nämlich, daß jene neuartigen Systeme ein "wesentlich günstigeres Preis/Leistungs-Verhältnis" und Möglichkeiten zur "starken Modularisierung und damit Vereinfachung der System- und der Anwendungssoftware" bieten; außerdem könne man sie "softwaretransparent" modular erweitern, sie also "kostenoptimal an die jeweilige Anwendung anpassen".
Nun sind dies alles zwar ganz beachtliche - theoretische - Vorzüge der Mehrrechner-Architektur, doch eines muß man sich doch stets vergegenwärtigen: Auch hier bekommt man nichts geschenkt, und auch hier kann man vieles falsch machen, beachtet man nicht einige wichtige Eckpunkte.
So kann man zum Beispiel nur dann auf ein befriedigendes Ergebnis hoffen, betonen die GMD-Mannen, wenn erstens eine leistungsfähige Kommunikationsstruktur vorhanden ist, die sogenannte "Kommunikations-Flaschenhälse" zwischen den
Teilsystemen vermeidet; wenn zweitens Schutzmechanismen vorhanden
sind, die das System sowohl gegen Programmierfehler als auch gegen
Fehlbedienungen "sicher und robust" machen, und wenn drittens die Systemsoftware auch wirklich stark standardisiert und modularsiert wurde; so stark, daß das System
durch weitgehend autonome: Untersysteme leicht erweitert werden kann - ohne daß man immer gleich auch die übrige Systemsoftware ändern muß.
Beachtet man alle diese Einschränkungen und Forderungen, so bleiben, sagen die vier Väter der modularen Unima, grundsätzlich nur zwei Möglichkeiten, real zum Ziel zu gelangen: Entweder baut man nämlich ein "lose gekoppeltes, verteiltes System" oder aber ein "stark gekoppeltes System". Im ersteren Falle hätte man dann einzelne, weitgehend autonom arbeitende Knoten, die miteinander durch den Austausch von Botschaften kommunizieren und kooperieren; das würde in etwa einem herkömmlichen lokalen Netz (LAN) entsprechen. Im zweiten Fall hingegen haben die einzelnen Teilsysteme Zugriff auf "Kommunikationsbereiche" in einem ihnen allen gemeinsam zugänglichen Speicher und außerdem, je nach der Konzeption auch noch die Möglichkeit, Botschaften individuell miteinander auszutauschen.
Für welche Konzeption man sich entscheidet, hängt, so meinen die Experten in Berlin, nun zum Beispiel davon ab, ob man etwa aus Gründen der Fehlertoleranz zu einem lose gekoppelten System greifen muß oder ob die anvisierte Anwendung es vielleicht verbietet, alle Komponenten eng gedrängt in ein und demselben Gehäuse unterzubringen. Trifft aber beides nicht zu, so läßt sich - wie hier im Falle der Unima - konkret an ein stark gekoppeltes System denken, denn das sei nun einmal "einfacher und bei vergleichbarem Aufwand leistungsfähiger" als die lose gekoppelte Konkurrenz.
Die Unima also ist ein stark gekoppeltes System, und sie soll, wie man aus Berlin hört, bezüglich der Flexibilität ihrer Konfigurierbarkeit sogar "im Augenblick ziemlich einmalig sein". Ihr schon erwähnter "Master"-Teil kann intern selber wiederum als Multiprozessor-System konfiguriert werden; er arbeitet als Unix-Maschine, stellt die Benutzeroberfläche her und führt die Aufsicht im Gesamtsystem. Ihn unterstützen Subsysteme, die entweder wie einfache Ko-Prozessoren arbeiten oder aber weitgehend autonom, wobei sie dann "Dienstleistungen für spezielle Anwendungen" erbringen. Dabei braucht aber der Benutzer sich nicht weiter um die Frage zu kümmern, wie der Master mit seinen Subsystemen denn nun eigentlich kooperiert und kommuniziert. Übrigens: Die Unima wird inzwischen von Firmen in Deutschland, England und den USA hergestellt.
Es wäre schön, könnte man die Unima hier in aller Ausführlichkeit beschreiben, doch leider ist dies aus Platzgründen nicht möglich. Einige kennzeichnende Besonderheiten aber lassen sich dennoch schlaglichtartig herausgreifen; sie sollen eine Vorstellung vermitteln, wie moderne Rechnerarchitekturen, unbeschwert von überkommenem Ballast, heute aussehen können.
Die Unima ist nach dem "Prinzip der hierarchischen Funktionsverteilung" konzipiert; von den Betriebssystem-Funktionen bis hinab zu den elementaren Operationen der Programmausführung sind ihre Funktionen also auf eine "geeignet strukturierte Hierarchie von physischen Maschinen" verteilt. Und zwar wurden
- Betriebssystem-Funktionen "horizontal" in periphere Prozessoren,
- Programmausführungsfunktionen "vertikal" in Ko-Prozessoren und
- Anwendungsfunktionen "vertikal" in autonom arbeitende Subsysteme verlagert.
CPU-Zeit-fressende Interruptvorgänge
Gerade am Beispiel des Betriebssystems Unix läßt sich gut zeigen, was diese Verlagerung konkret an Nutzen bringen kann. Denn Unix arbeitet ja mit einem ausgefeilten Puffersystem und einer geräteunabhängigen Schnittstelle für die Integration fast beliebiger Ein-/Ausgabe-Geräte durch Gerätetreiber. Jene beanspruchen für gewöhnlich einen wesentlichen Teil der verfügbaren CPU-Leistung, zumal die interaktive Arbeitsweise von Unix auch noch zu dauernden, CPU-Zeit fressenden Interruptvorgängen (Unterbrechungen) führt. Außerdem bewirkt das Unix-typische häufige Ein- und Auslagern von Prozessen, das sogenannte Swapping, eine Belastung der CPU mit - teilweise auch noch recht ineffizienten - Aufgaben. Das alles kostet Leistung.
Überträgt man nun allein die "zeichenweise" erfolgende Ausgabe einem peripheren Prozessor statt der CPU, so erhält man, wie die GMD-Forscher gesehen haben, bereits eine rund dreißigprozentige (!) Leistungssteigerung. Und ein ähnliches Plus bringt auch die Verlagerung der "zeichenweisen" Eingabe.
Weiterhin kann man den "blockweise" erfolgenden Datentransport von und zu den Platten einem eigenen peripheren Prozessor übertragen und dann gleich auch einen schnellen, direkten Speicherzugriff (DMA) vorsehen. Will man noch weiter gehen, so läßt sich ein Teil des UNIX-Betriebssystem-Kerns "horizontal" in besondere, periphere Prozessoren verlagern. Und "vertikal" schließlich kann man "Objekte und Funktionen komplexer, anwendungsspezifischer Datentypen günstig in spezielle, typenspezifische Ko-Prozessoren" verlagern; dann erreicht man nämlich bei der Bearbeitung eben dieser Datentypen Beschleunigungen um "Faktoren zwischen 50 und 500".
Wie so eine, auf mehrere Prozessoren verlagerte UNIX-Maschine aussehen kann, zeigt das Beispiel einer Konfiguration mit einer UNIX-CPU samt Speicherverwaltungseinheit für den segmentierten, virtuellen Speicher des Systems, "UCPU" genannt, einem Hauptspeicher bis maximal 15 MB, einem Zeichen- und einem Block-Ein-Ausgabe-Prozessor (CIOP und BIOP), einem Netzwerk-Prozessor (NIOP) und einem Grafik-Prozessor (GKSP). Dabei können alle diese BIOP, CIOP und so weiter ebensoviel Leistung bringen wie die Zentraleinheit, denn wie jene basieren auch sie alle auf einem Prozessor des Typs Motorola 680 10.
So viele schnelle Prozessoren brauchen einen sehr schnellen Bus mit einem effizienten Zuteilungsverfahren, um miteinander und mit dem Speicher ohne Wartezustände kommunizieren zu können. In Berlin wurde dazu eigens ein 16 MB/s übertragender, sogenannter Easybus entwickelt, der mit einem ebenfalls neu entwickelten, sehr schnellen Arbitrierungs- (Zuteilungs-)Verfahren arbeitet. Hierbei kann binnen je 60 Nanosekunden der Zugriff von bis zu sieben Bus-Mastern auf den zentralen Speicher arbitriert werden, wobei diese sieben alle die gleiche Zugriffschance haben. Der kürzestmögliche Buszyklus dauert 125 Nanosekunden.
Die Prozessoren der Unima greifen über den Bus auf Kommunikationsbereiche im zentralen Speicher zu, verfügen aber auch über private Programm- und Datenpufferspeicher. Die Speicherschutzmechanismen begrenzen bei Benutzerprogrammen den Zugriff strikt auf bestimmte Speicherbereiche, während bei der internen Kommunikation des Systems (zwischen UCPU und den anderen Prozessoren) aus Gründen der Effizienz kein solcher Schutz besteht. Man geht in Berlin hoffnungsvoll davon aus, daß man mit hinreichend erprobter und mithin "korrekter" System-Software arbeitet.
Da die Unima als "Testbed" für innovative Multiprozessor-Architekturen gedacht und auf der Ebene des Betriebssystems kein Speicherschutz vorgesehen ist, wurde von den GMD-Forschern eine besondere, zweigeteilte Rechnerstruktur entwickelt, auf die hier leider nicht näher eingegangen werden kann; sie dient jedenfalls dazu, das eigentliche Testbed-System, bei dem man während der Experimentier- und Entwicklungsphase ja mit häufigen Systemzusammenbrüchen rechnen muß, vom UNIX-Software -Entwicklungssystem zu trennen. Dabei kommt in beiden, über einen Buskoppler verbundenen Teilen der Easybus zur Anwendung.
Das Mehrprozessor-Testbedsystem kann mit maximal acht Grundbausteinen, den Special Computation Processors (SPC), bestückt werden die jeweils auf einer Platine Platz haben und aus dem Prozessor 68010, wahlweise auch aus einem zusätzlichen Gleitkomma-Prozessor, aus 64 KByte EPROM, bis zu 512 KByte RAM und weiteren Einheiten bestehen. Zu den letzteren zählen auch bestimmte, multifunktionale Bausteins, über die jeder SPC jedem anderen Prozessor inklusive der UCPU einen Interrupt-Befehl senden (oder von ihm empfangen) kann.
Weiterhin verfügen die Platinen über "datenflußgesteuerte Kommunikationskanäle", die zum wechselseitigen Austausch von Botschaften dienen; hierbei erfolgt dann jeweils gleich eine "Datenfluß-Synchronisation".
Einzigartige Kombi-Kommunikation
Die Berliner GMD-Wissenschaftler heben nun aber hervor, es seien weniger die Details als vielmehr "die einzigartige Kombination von Kommunikationswegen", was den "besonderen Reiz dieses Systems" bilde. Denn hier gebe es erstens Verbindungen über serielle Schnittstellen, zweitens Verbindungen über Kommunikationsbereiche im gemeinsamen Speider und drittens auch noch Verbindungen über Datenfluß-Botschaften-Puffer.
Mit diesem vielfältigen Instrumentarium kann man die Prozessoren in einem ersten Schritt nur lose. Aber die V.24-Schnittstellen, koppeln. In einer nächsten Stufe wären dann die Prozessoren - hat man es mit größeren Datenmengen zu tun und muß die Kommunikation beschleunigt werden - über Speicher "fest" zu koppeln. Dabei lassen sich, heben die GMD-Autoren hervor, "zusammen mit dem universell angelegten Netzwerk von Interrupt-Leitungen im Prinzip alle Konzepte der Inter-Prozeß-Kommunikation implementierend". Man könne also Strategien wie ",Monitore', ,Interrupt Driven Messages', ,Busy Wait' und andere" erproben, wozu im zentralen Speicher nur noch Bereiche für die Kommunikation (Semaphore, Botschaften-Puffer, Mailboxes und so weiter) angelegt werden müssen.
Schließlich können aber auch, und dies ist nun die "mächtigste" Art von Kopplung, die datenflußgesteuerten Kommunikationskanälen eingesetzt werden, indem man das Kommunikations-Interface jeder SCP-Einheit heranzieht. So sollen sich sogenannte Datenfluß- und auch Pipeline-Konzepte in besonders effizienter Weise implementieren lassen.
Die Unima mit ihren SCP-Einheiten ist so angelegt, daß - je nach Anwendungsfall - in den einzelnen SPCs völlig unterschiedliche Software-Routinen laufen können. Die müssen aber keineswegs alle in den (programmierbaren) EPROMs der SCPs gehalten werden, denn das würde die Flexibilität und auch die Wartungsmöglichkeiten der Software beeinträchtigen. Schließlich gibt es andere Wege.
Das System bietet die höchst attraktive Möglichkeit, Software auf der Unima zu entwickeln und zu übersetzen, wobei man alle verfügbaren Programmiersprachen benutzen kann. Diese Programme kann man anschließend in den - durchaus stattlich bemessenen - privaten Speicher der einzelnen SCPs laden; in Vorgang, der beliebig oft wiederholt werden kann. Und das führt nun sogar dazu, daß die Unima spezielle Prozesse "dynamisch auf gerade freie Prozessoren des Testbedsystems verlagern" kann, das wäre dann übrigens eine Anwendung, bei der die SCPs - ohne dabei wechselseitig miteinander zu kommunizieren - als "reine Beschleuniger" fungieren.
Forschungsmaschinen wie die Unima werden nicht nur entwickelt, weil man mit interessanten Konzepten spielen möchte, sondern auch, weil man für sie interessante Nutzanwendungen sieht. - Ist dies auch bei der Berliner GMD-Entwicklung so?
Die Unima, so sagen Brüning, Giloi, Kallerhoff und Rüsse, könne beispielsweise als Testbed beziehungsweise Emulator für einen PROLOG Parallelrechner genutzt werden, der ich derzeit in Entwicklung befindet. Dabei werden die SCPs zu einer "Pipeline" (Fließband) von asynchron kooperierenden "Unifikations-Prozessoren" zusammengekoppelt. In einer weiteren Anwendung könne die Unima eine parallel arbeitende, sogenannte "Reduktionsmaschine" emulieren, wobei die SCPs hier die Reduktion einer Menge von Ausdrücken gleichzeitig durchführen. Oder sie wird als Simulator für "kontinuierliche System" auf der Grundlage von geeigneten Simulationssprachen betrieben.
Zum Gebiet der MIMD-Anwendungen gehört aber auch die Idee, die Unima als Testbed für die Entwicklung von Organisationsformen beziehungsweise Synchronisationsmethoden für numerische MIMD-Anwendungen sowie zur Entwicklung der vorstehend geforderten MIMD-Sprachen selber einzusetzen.
Dies alles sind bereits durchaus ehrgeizige Forschungs- und Erprobungskonzepte, die auch dem Außenstehenden ein Gefühl für die große Flexibilität und das hohe Leistungspotential einer Architektur beziehungsweise einer Implementierung dieser Architektur, wie die Unima sie darstellt, vermitteln können. Und dennoch sind die Möglichkeiten dieses Konzepts noch weiter gespannt, wie das abschließend folgende Beispiel einer Konfiguration zeigen soll, die die GMD-Forscher zusammen mit einem Lizenznehmer im High-Tech-Mekka USA realisieren. Sie soll, läuft erst einmal alles, zu einem "FIexible Workcell Controller System bisher unerreichter Funktionalität und Leistung" führen.
Diese neue Konfiguration nutzt die schon kurz angedeutete Möglichkeit, eine Unima durch in sich vollständige, autonom arbeitende Untersysteme immer noch weiter auszubauen. Denn in einem Workcell-Controller für Produktionszellen müssen ja in ein und demselben System vielfältige Funktionen integriert sein: die Bildanalyse oder auch "machine vision", die Steuerung externer Effektoren und Manipulatoren wie zum Beispiel Roboter und NC-Maschinen, der Zugriff auf eine gemeinsame, integrierte Datenbasis und dann natürlich auch noch die Koordination der hier genannten Funktionskomplexe.
Sicher könnte man, im Sinne herkömmlicher Konzepte, mit einem lokalen Netz arbeiten, das die verschiedenen, bei so einem Controller eingesetzten Teilsysteme miteinander verbindet. Doch mit der Unima komme man, dank deren flexiblem Architekturrahmen, "wesentlich effizienter und kosteneffektiver" zum Ziel, sagen die Experten der GMD.
Sie haben dabei eine Lösung vor Augen, bei der ein aus UCPU, BIOP und CIOP bestehendes Unix-Mehrrechnersystem erstens die Benutzeroberfläche bereitstellt und zweitens die allen Teilsystemen gemeinsame Datenbasis verwaltet und bei der ein Netz- Ein-Ausgabe-Prozessor (NIOP) die Einbindung der Gesamtmaschinerie in ein LAN oder auch ein Weitverkehrs-Netz ermöglicht.
Das ist noch bei weitem nicht alles. Denn zur bisher erwähnten Hardware treten nun noch weitere, den UNIX-Master ergänzende Untersysteme; sie werden dadurch gebildet, daß jeweils einer der maximal sieben Prozessoren auf dem Easybus selber wieder als Zentraleinheit eines vollständigen und somit autonom arbeitsfähigen Subsystems fungiert. Doch anders als ein gewöhnlicher Ko-Prozessor arbeiten diese CPUs unter ihrem jeweils eigenen Betriebssystem.
Ein Beispiel für ein Subsystem ist etwa das in Berlin erprobte VME-Bus-Subsystem (VIOP), das zum Anschluß von Produkten auf VME-Bus-Basis dient und das eine Reihe von Steuerungsaufgaben übernehmen kann. Ein zweites Beispiel ist das Vision-Subsystem (VCPU), das mit dem "IRI-Bus" der Firma International Robomation/Intelligence arbeitet und über ihn alle einschlägigen Bilderkennungs-Bausteine nutzen kann.
Von diesen Vision-Subsystemen kann man sogar zwei oder drei einsetzen und so beispieIsweise zur stereoskopischen Bildverarbeitung gelangen. Dabei ist hier ein multifunktionaler Einplatinen-Arrayprozessor besonders erwähnenswert, der, so die GMD-Mannen, pro Sekunde bis zu 50 Millionen arithmetische Operationen ausführen kann; es sei mithin leicht, "die Bildverarbeitungsleistung einer Cray-1 zu übertreffen".
Doch hier interessiert uns primär die Berliner Entwicklung Unima, und dazu muß abschließend nun noch bemerkt werden, daß die auf den einzelnen Subsystemen ablaufenden Routinen aus der Sicht des Unima-Benutzers einfach bloß "Prozesse des UNIX-Systems" sind, in denen daher die gleichen Ein-Ausgabe-Anweisungen auftreten dürfen wie auch in den Prozessen, die auf dem Master-System laufen. Für den Anwendungsprogrammierer einer Unima ist die Tatsache, daß hier auch Subsysteme mit sogar noch eigenen Betriebssystemen vor sich hin arbeiten, völlig "transparent".
Parallelverarbeitung
Zu den Themen, die in EDV-Kreisen mehr und mehr Interesse finden, gehört die parallele Datenverarbeitung, also die Abkehr vom herkömmlichen Uni-Prozessor. In einer Losen Folge themengerichteter Beiträge beleuchtet die COMPUTER-WOCHE dieses Gebiet, ohne aber Systematik oder enzyklopädische Vollständigkeit anzustreben.
Bisher erschienen Beiträge in dieser Reihe in den Ausgaben 20/85 (Seite 58), 22/85 (Seite 56), 25/85 (Seite 56), 25/85 (Seite 76), 28/85 (Seite 18) und 41/85 (Seite 60).