Am Scheideweg sieht die International Data Corporation (IDC) die Entwickler derzeitiger 32-Bit-Minicomputer angelangt. In ihrer jüngsten Studie "Supermini Technologies: The Outlook for Medium Scale Systems" geht die IDC der Frage nach, wie super die Superminis heute sind. Der folgende Beitrag ist dem EDP Deutschland Report* der IDC entnommen und befaßt sich mit einigen grundsätzlichen Betrachtungen zur Zukunft der Superminis und ihrer Anbieter.
Der Markt für Medium-Scale-Computer wird heute von Systemen dominiert, die üblicherweise als "Superminis" bezeichnet werden. Anders als Mikrocomputer und die Mehrzahl der Small-Scale-Systeme basieren die meisten Computer im Medium- und Large-Scale-Bereich auf herstellereigenen "Board-level"-Architekturen. Die Komponenten der CPU bei Superminis arbeiten sehr häufig in TTL-Logik ("Transistor-to-Transistor"), wenngleich in jüngerer Zeit auch ECL-Logik ("Emitter-Coupled-Logic") zu finden ist. Hersteller, die mehrere Zentralverarbeitungselemente in eine einzige Maschine packen, setzen durchweg auf MOS-Technologie ("Metal Oxide Semiconductor").
Nun sind in letzter Zeit eine Reihe von Superminis auf dem Markt erschienen, die auf Mikroprozessoren aufbauen. Viele der Etablierten verhalten sich bislang ablehnend oder zumindest zurückhaltend. Aber auch sie wissen wohl, daß immer bessere Mikroprozessoren die traditionellen Superminiarchitekturen mit herstellereigenen CPUs substantiell gefährden. AT&T etwa liefert in den USA bereits Musterstückzahlen eines 32-Bit-Mikroprozessor-Chipset, das eine Leistung von 4 Mips bringen soll.
IBM und DEC behaupten Medium-Scale-Markt
Nachfolgend sind die wichtigsten neuen technologischen Ansätze im Superminibereich und, soweit sinnvoll, auch die darin involvierten Unternehmen beschrieben. Dabei darf man jedoch nicht aus dem Auge verlieren, daß IBM und DEC zusammen mit sehr konventionellen Architekturen gut die Hälfte des Medium-Scale-Marktes abdecken. Die zahlreichen Newcomer der Szene werden daran wohl auch auf absehbare Zeit nicht viel ändern können.
Schon seit jeher war "Eleganz" ein entscheidendes Motiv für Innovationen der Informatik. Die RISC-Technologie ("Reduced Instruction Set Computer") ist ein typisches Beispiel einer Ausgeburt des "Eleganz-Gedankens" der Mathematik und der Informatik.
RISC-Architekturen basieren auf Instruktionssätzen mit relativ wenigen, dafür aber sehr mächtigen Befehlen. Sie verlegen also die Operationen weitgehend auf die Siliziumebene. Als Gegenteil zu RISC wird das Akronym CISC für "Complex Instruction Set Computer" verwendet.
Ob sich RISC gegen CISC wird durchsetzen können, dürfte weitgehend von der Frage bestimmt werden, welche der beiden rivalisierenden Technologien die größere Verarbeitungseffizienz mit sich bringt. Dabei scheint RISC im Durchsatz eindeutig vorne zu liegen. Das resultiert auch aus der Tatsache, daß eine RlSC-Architektur von ihrer Konzeption her besser für alle Arten von Pipelining geeignet ist als CISC. Nachdem der Hardware ein mächtiger Befehl überantwortet wurde, kann diese selbständig Pipelining betreiben, da sie eben alle Einzelinstruktionen auch für einen sehr komplexen Prozeß bereits kennt. CISC-Architekturen sind hier wesentlich mehr auf vorausschauende Annahmen angewiesen. Pipelining gewinnt allerdings zunehmend bei beiden Technologien an Bedeutung. So arbeitet beispielsweise die VAX 8650 als Quintessenz einer CISC-Architektur mit einem vierstufigen Pipelining-Konzept.
Häufig wird in der Diskussion um RISC der vermeintliche Vorteil angeführt, diese auf Schlichtheit basierende Architektur komme dem Programmierer entgegen. Dieses Argument ist angesichts der zunehmenden Hochsprachenprogrammierung kaum haltbar. Entscheidend dürfte vielmehr sein, wie weitgehend Compiler aus RISC ihre Vorteile ziehen können. In dieser Hinsicht ist durchaus einiges zu erwarten.
IBM hat mit der Vorstellung des RT PC (IBM 6150) gezeigt, daß sie gewillt ist, auf RISC zu setzen. Nun sind Workstations wie der RT PC ein typisches RlSC-Einsatzgebiet. Ein anderer ebenso typischer Bereich sind Superminis. Es ist anzunehmen, daß IBM über kurz oder lang mit einem RISC-Supermini aufwartet. Immerhin wäre für IBM eine Cobol-orientierte RISC-Architektur eine lohnende Herausforderung.
Dabei stellt sich nicht nur für IBM die Frage, inwieweit sich RISC in bereits bestehende Produktreihen integrieren läßt. RISC ist nämlich eine Erfindung von eher theoretisch orientierten Akademikern, bei denen die Zahlenverarbeitung im Vordergrund steht. Für "Zahlenfressereinsätze" ist RISC unzweifelhaft geeignet. Wie steht es aber mit kommerziellen Anwendungen, wo Aspekte der Ein- und Ausgabe sowie der Speicherverwaltung oftmals von größerer Bedeutung als der nackte Mips-Durchsatz sind? Die Suche nach Architekturen, die den "RISC-Motor" nicht mit E/A- und Speicheraufgaben überbelasten, dürfte! wohl noch eine Weile andauern.
Der "Zahlenfresserhintergrund" ist mit ausschlaggebend dafür, daß die RlSC-Architektur bislang prima in technisch-wissenschaftlichen Workstations und Superminis Einzug gehalten hat. Ein anderer Grund liegt darin, daß diese beiden Märkte besonders hellhörig sind, wenn von Unix die Rede ist. Sowohl Unix als auch RISC zielen nämlich beide in Richtung einer stark verbesserten Softwareportabilität. Je weniger Instruktionen vorhanden sind, desto weniger Portierarbeit ist zu leisten. Bedenkt man, daß gerade der Aspekt der Übertragbarkeit von Software immer mehr in den Vordergrund drängt, so könnte dies durchaus ein wichtiges Argument für RISC werden.
Die Emulation von Architekturen ist ein anderer sehr interessanter Aspekt von RISC. Es ist naturgemäß wesentlich einfacher, einen komplexen Befehlssatz einer Architektur in einen RlSC-Befehlssatz umzusetzen als ihn auf eine andere, ebenfalls komplexe Architektur zu übertragen. Eine Emulation unter RISC ist aber nicht nur einfacher durchzuführen, sondern im Ablauf auch schneller als jede CISC-Emulation.
Hewlett-Packards erste Modelle einer RISC-Produktfamilie sind voll softwarekompatibel zu der bestehenden HP-3000-Serie - und zwar ohne Neukompilierung. Nach HP-Angaben entspricht die Leistung denen der bisherigen CISC-Maschinen. Die wirklichen Vorteile von RISC treten natürlich erst bei Rekompilierung von RISC angepaßter Software zutage. Hewlett-Packard versorgt also einerseits seine Kunden mit der neuen Technologie, sichert aber andererseits deren Software-Investitionen. Es steht zu erwarten, daß andere Anbieter ähnliche Wege gehen werden.
Vermutlich wird über kurz oder lang kein Hersteller an RISC vorbeikommen. Mit IBM, DEC, Hewlett-Packard, Nixdorf und anderen sind große Namen bereits RISC-orientiert. HP scheint sogar ein bißchen seine Zukunft auf RISC zu setzen, etwa so, wie Perkin-Elmer auf Parallelverarbeitung baut. Es wird interessant sein, diesbezügliche Aktivitäten Hewlett-Packards zukünftig zu beobachten .
Während es sich bei RISC um eine Prozessorarchitektur handelt, zielen Multiprocessing und Parallelverarbeitung auf den Bereich der Systemarchitektur. Dabei sei darauf hingewiesen, daß es sehr empfehlenswert ist, die einzelnen Begriffe (und deren Inhalte) klar auseinanderzuhalten. "Parallele Datenverarbeitung" ist ein derart schillerndes Schlagwort, daß es schwer sein dürfte, zwei Menschen zu finden, die exakt das gleiche darunter verstehen.
Die klassische Datenverarbeitung beruht auf dem Von-Neumann-Prinzip, das 1946 von John von Neumann in Zusammenarbeit mit W. Burks und Herman H. Goldstein postuliert wurde. Der im Zusammenhang mit Parallelverarbeitung wichtige Aspekt ist, daß von Neumann eine durch und durch sequentielle Verarbeitung der Daten beschreibt, deren Prinzip darin gipfelt, jeden Prozeß soweit wie möglich in Einzelschritte zu zerlegen, die sodann nacheinander ausgeführt werden.
Wenn heute von Multiprocessing und paralleler Datenverarbeitung die Rede ist, dann muß man einige Begriffe unterscheiden.
Multiprocessing. Ein Computer ist ein Multiprozessorsystem, wenn er mehrere Aufgaben auf mehreren Prozessoren zur gleichen Zeit abarbeiten kann. Multiprocessing dient in erster Linie der Durchsatzsteigerung, etwa im Bereich interaktiver Mehrplatzsysteme.
Bei Multiprocessing arbeiten alle Prozessoren unter einem einzigen übergeordneten Betriebssystem, das die Abläufe koordiniert. Entweder sollen in einer Multiuser-Umgebung die Benutzer schneller bedient oder aber in einer Singleuser-Umgebung der Ablauf eines Programms beschleunigt werden. Im ersten Fall spricht man häufig von "Multitasking", im zweiten Fall zuweilen von "echter Parallelverarbeitung". Beide Ansätze lassen sich auch in einem System kombinieren.
Weitgehend unabhängig von der Systemarchitektur ist die CPU-Architektur. Es kann sich um einen herkömmlichen Mikroprozessor (Sequent Balance 8000), einen RISC-Prozessor (Pyramid 98x) oder einen Vektorprozessor (Cray XMP) handeln. Multitasking muß nicht notwendigerweise mit Multiprocessing verknüpft sein. Minis und Superminis haben schon immer auch Multitasking-Aufgaben wahrgenommen, bei nur einem Prozessor mittels Timesharing.
Parallelverarbeitung - schillerndes Schlagwort
Auch Vektorprocessing läßt sich auf Uniprozessorsystemen abwickeln, bietet sich jedoch ähnlich wie Multitasking besser für Multiprozessorsysteme an. Bei Vektorverarbeitung wird eine einzelne Anweisung auf ein Datenfeld (einen Datenvektor) angewendet. Mit nur einer Instruktion werden also viele Daten auf einmal bearbeitet. Derartige Systeme basieren durchweg auf ausgeklügelten Pipelining- und Register-Architekturen. Vektorprocessing assoziiert man herkömmlicherweise hauptsächlich mit Supercomputern und speziellen Vektormaschinen. Es ist im Grunde eine Form der parallelen Datenverarbeitung.
Parallele Datenverarbeitung. Ein Computer ist ein parallel verarbeitendes System, wenn entweder eine einzelne Anweisung auf mehrere Daten gleichzeitig einwirkt, oder aber wenn mehrere Prozessoren an der Ausführung eines einzelnen Programms beteiligt sind. Ein klassisches Beispiel für die erstgenannte Art von Parallelverarbeitung ist die Cray 1. Für die Multiprozessor-Parallelverarbeitung eines einzelnen Programms gibt es heute noch kein klassisches Beispiel. Die wenigen kommerziellen Ansätze in dieser Richtung müssen ihre Erfolgsträchtigkeit erst noch beweisen, die weitaus meisten Systeme dienen heute noch experimentellen Zwecken.
Als einzigen "wahren" Verfechter der Parallelverarbeitung aus der etablierten Superminiriege muß man Perkin-Elmer nennen. Diese Neigung resultiert wohl im wesentlichen aus zwei Tatsachen: Erstens ist Perkin-Elmer im technisch-wissenschaftlichen Bereich angestammt, wo Neuerungen generell offener aufgenommen werden als etwa in der kommerziellen DV; zweitens hält Perkin-Elmer in dem genannten Bereich nur einen kleinen Marktanteil, so daß das Unternehmen darauf angewiesen ist, sich zu profilieren. Nach der kürzlich erfolgten Auslagerung der DV-Aktivitäten in die Concurrent Computer dürfte P-E zukünftig noch verstärkt auf Parallelverarbeitung setzen.
Machbar sind drei Architekturen
Ein Vorreiter wie Perkin-Elmer ist auch durchaus notwendig, denn in bezug auf die Systemarchitektur parallelverarbeitender Systeme sind heute noch viele Fragen offen. Es gibt bislang keine überzeugende Lösung für das Problem, mehrere Prozessoren an einer gemeinsamen Aufgabe effizient einzusetzen. Alle bisherigen Lösungsansätze sind insofern unbefriedigend, als entweder das Applikationsprogramm viel zu stark an die Parallelarchitektur angepaßt werden muß oder aber die Effizienz recht gering ist. Das gilt insbesondere dann, wenn mehrere Prozessoren gleichberechtigt eingesetzt werden sollen.
Grundsätzlich kann man zwischen drei Möglichkeiten, wie Prozessoren in einer Parallelarchitektur gekoppelt werden können, unterscheiden: lose gleichberechtigte Koppelung (koordinierte Jobverarbeitung), Master-Slave-Koppelung und enge gleichberechtigte Koppelung (prozessororientierte Jobverarbeitung) Diese Aufzählung bedeutet nicht, daß nicht noch ganz andere Architekturen denkbar sind; derzeit machbar sind aber nur die drei genannten.
Lose gleichberechtigte Koppelung. Bei dieser Prozessorkonfiguration hat jeder Prozessor ein eigenes Interrupt-System und einen eigenen Speicherbereich. Statt von "Multiprocessing" sollte man besser von "Multicomputing" sprechen, da die Prozessoren nicht von einem übergeordneten einzelnen Betriebssystem gesteuert werden, sondern jeder Prozessor unter einem eigenen Betriebssystem läuft (wobei die Betriebssysteme aber nicht notwendigerweise unterschiedlich sein müssen; zum Beispiel können fünf Prozessoren unter fünf Kopien des gleichen Unix-Systems laufen). Die Prozessoren arbeiten unabhängig voneinander und führen verschiedene Programme oder separate Teile eines Programms aus. Der Datenaustausch erfolgt über einen gemeinsamen Speicherbereich aller Prozessoren, auf den häufig nur mit niedrigerer Geschwindigkeit zugegriffen werden kann als auf jeden jeweils prozessoreigenen Speicher. Das VAXCluster-System ist ein typisches Beispiel für eine solche Konfiguration.
Master/Slave-Koppelung. Hierbei handelt es sich um eine lose gekoppelte Multicomputing-Architektur, bei der ein Masterprozessor die übergeordnete Steuerung übernimmt und die anderen Prozessoren "nur Koprozessoren (Slaves) sind. Häufig kommen Mikroprozessoren zum Einsatz, "Board-level"-Architekturen sind seltener anzutreffen. Nur der Masterprozessor erhält die eigentliche Verarbeitungsaufgabe, die Koprozessoren bekommen vom Master untergeordnete Aufgaben zugewiesen. Als Slaves kommen sowohl GP(General Purpose)-Prozessoren als auch Spezialprozessoren (beispielsweise Arithmetik-Koprozessoren) in Frage.
Enge gleichberechtigte Koppelung. In dieser Architektur sind alle Interrupt-Systeme, Speichereinheiten und E/A- Kanäle für alle Prozessoren in gleicher Weise zugänglich. Die Zuteilung der Ressourcen erfolgt weitgehend dynamisch. Von besonderem Interesse ist das Prinzip, mit dem die Prozessoren mit Aufgaben versorgt werden. Im allgemeinen werden die abzuarbeitenden Jobs in einem dafür reservierten Speicherbereich abgelegt, aus dem sich die Prozessoren eigenständig bedienen. Die Hauptprobleme bei diesem Konzept sind die Verteilung der Ressourcen und die Synchronisation der Aufgaben. Das Betriebssystem muß ständig für eine einigermaßen gleichmäßige Aufteilung sorgen, damit die Verarbeitungseffizienz möglichst groß ist.
Software-Anpassung unvermeidlich
Sowohl bei der Master-Slave-Koppelung als auch bei der engen gleichberechtigten Koppelung stellt sich die Architektur aus der Sicht des Programmierers als ein einziges homogenes System dar. Das hat den entscheidenden Vorteil, daß herkömmliche Programme ohne aufwendige Umsetzungsarbeiten eingesetzt werden können. Um allerdings zu einer weitergehend parallelen Verarbeitung zu gelangen, ist die Anpassung der Software unvermeidlich - gleichgültig, mit welcher Architektur gearbeitet wird. Ohne Anpassung können allenfalls Ansätze zur Parallelverarbeitung erreicht werden.
Aus heutiger Sicht sieht das Prinzip der engen gleichberechtigten Koppelung am vielversprechendsten aus. Das muß aber keineswegs heißen, daß dies die Parallelarchitektur der Zukunft ist" Denn es ist unzweifelhaft, daß das letzte Wort in dieser Hinsicht noch nicht gesprochen ist.
Eine der spektakulärsten Unternehmensgründungen im Bereich parallelverarbeitender Superminis, Encore, setzt beispielsweise auf eine enge gleichberechtigte Prozessorkoppelung. Allerdings erzielte die 1983 gegründete Encore mehr Aufsehen durch das Management als durch die Produkte; die Gründerliste liest sich wie ein Auszug aus "Who's Who in Minicomputing": Kenneth G. Fisher (Prime-Präsident von 1975 bis 1981), C. Gordon Bell (ehemals Cheftechniker und Vizepräsident Ingenieurwesen bei DEC), Henry Burkhardt III (Mitgründer von Data General und Vizepräsident Finanzwesen/ Verwaltung über acht Jahre), Robert G. Claussen (Vertriebschef bei Prime über sieben Jahre).
Gutes Verhältnis Durchsatz/Kosten
Encores Multimax-Produktfamilie stützt sich voll auf den 32-Bit-Mikroprozessor NS32032 von National Semiconductor. Jeweils zwei 10-MHz-32032 sind auf einer Karte untergebracht, insgesamt lassen sich maximal zehn solcher Karten installieren. Der Speicher kann ebenfalls mit 4-MB-Steckkarten kontinuierlich ausgebaut werden, er wird von allen Prozessoren gleichberechtigt benutzt. Der Einsatz des NS32032 drückt Encores Vorliebe für Standardbauelemente aus. Daher ist es nicht verwunderlich, daß es sich bei dem Betriebssystem um Unix handelt .
Sequent setzt ebenso wie Encore auf den NS32032-Mikroprozessor. Bis zu acht 32032 stehen in der Balance 8000 unter der Kontrolle einer herstellereigenen Multiprozessor-Management-Einheit. Die 32032-Prozessoren sind völlig gleichberechtigt, die Ressourcen- und Aufgabenzuteilung erfolgt zentral durch das Betriebsystem, das sich dem Programmierer als eine einheitliche Oberfläche präsentiert. Das System wird vom Marketing her eher als durchsatzstarker Supermini denn als Parallelverarbeitungscomputer positioniert. Bestehende Software braucht nicht auf die Multiprozessorumgebung adaptiert zu werden. Wenn man dies dennoch vornimmt, ergeben sich allerdings immense Vorteile in der Abarbeitungsgeschwindigkeit. Sequent forciert daher in letzter Zeit diesen Aspekt zunehmend. Dennoch läßt sich wohl sagen, daß der Erfolg dieser Parallelarchitektur (vorläufig) darauf beruht, daß sie herkömmliche Software ohne Adaption mit einem sehr guten Durchsatz/Kosten-Verhältnis verarbeiten. Der Aspekt der Parallelverarbeitung ist daher eher von untergeordneter Bedeutung.
Nur ein Bruchteil an Kosten
Während in der kommerziellen DV Vektorverarbeitung nur eine untergeordnete Rolle spielt, ist sie in den technisch-wissenschaftlichen Anwendungen von enormer Bedeutung. Die Hochleistungsvektormaschinen sind jedoch durchweg Supercomputer und für viele Anwender unerschwinglich. Weltweit sind heutzutage weniger als 200 Supercomputer im Einsatz - nicht, weil nicht mehr gebraucht würden, sondern weil viele Budgets zu klein sind. Die Lücke in Leistung und Preis zwischen Supercomputern einerseits und Superminis und Mainframes mit technisch-wissenschaftlicher Orientierung andererseits ist das Ziel einer neuen Mini-Supercomputer-Generation. Diese Geräte können zwar nur einen Bruchteil der Leistung von Supercomputern erbringen, verursachen aber auch nur einen noch viel geringeren Bruchteil an Kosten.
Dieses Marktsegment bleibt allerdings keineswegs nur den Superminis Herstellern vorbehalten; die traditionellen Mainframe-Anbieter kämpfen ebenfalls darum, wie IBMs Ankündigung eines Vektorprozessorzusatzes für die 3090 bewiesen hat. Die Supermini-Anbieter haben einen entscheidenden Vorteil auf ihrer Seite: Sie verkaufen seit langem an technisch-wissenschaftliche Anwender, während die herkömmlichen Mainframes überwiegend in kommerzielle DV-Einsatzgebiete fließen. Es ist stets einfacher, an Kunden zu verkaufen, die bereits Kunden sind, als potentielle in tatsächliche Kunde umzuwandeln.
Mini-Super noch keine Bedrohung
Die Anbieter der "Baby-Crays" auf Superminibasis stützen sich im allgemeinen auf eine von zwei Kompatibilitätsschienen: Cray oder VAX. Einige Newcomer versuchen, mit völlig neuen Ansätzen zu überzeugen und neue Standards zu setzen, ohne daß bislang ein Gelingen abzusehen ist. Sehr gute Beispiele für die Anbieter von Supermini-"Crayettes" sind Scientific Computer, Floating Point Systems und Allient.
Nun beeinflussen die Mini-Super natürlich nicht nur den Supercomputermarkt, sondern auch den Markt der Superminis. Es stellt sich die Frage, ob sich die Supermini-Anbieter mit dem Minisuper-Ehrgeiz nicht das Wasser des eigenen Marktes abgraben. Aus heutiger Sicht muß die Antwort "Nein" lauten. Es sieht eher so aus, als eröffne sich hier eine neue Nische, die zwar schon den obersten Superminibereich leicht tangiert, aber keineswegs große Auswirkungen auf den Superminimarkt haben wird. Wer die Entwicklung der Mini-Super als Ansatz der Bedrohung herkömmlicher Supercomputerarchitekturen versteht, geht wohl ebenfalls zu weit. Auf absehbare Zeit stellt sich keine Alternative zur Leistung heutiger Supercomputer.