Für die Leistung eines Computersystems kann die Architektur von wesentlich höherer Bedeutung sein als die Anzahl der Instruktionen pro Zeiteinheit. In Ergänzung zu Mips oder Standard-Benchmarks, so die Unternehmensberaterin Maryla Schmidt aus Neubiberg/München, sollten auch die angebotenen Computerarchitekturen analysiert werden.
Die Architektur herkömmlicher Systeme ist oder war ursprünglich sehr "geradeaus": in der Mitte die Zentraleinheit, daran radial angeschlossen ein oder mehrere Speichereinheiten und die Ein-/Ausgabesteuerung. Man könnte diese Struktur daher die der "ersten Art" nennen.
Computer dieser "ersten Art" sind dann sinnvoll, wenn es auf reine interne Verarbeitungsgeschwindigkeit ankommt, oder wenn Datenerfassung ohne viel gleichzeitige Verarbeitung durch die Zentraleinheit gefordert wird.
Meßkriterium der internen Geschwindigkeit sind die häufig zitierten Mips (Millionen Instruktionen pro Sekunde). Das leuchtet ein: je schneller der durchschnittliche Maschinenbefehl abgearbeitet wird, je schneller ist im Normalfall das ganze Programm fertig. Zwar spielen hier auch noch andere nicht ganz unwichtige Dinge - wie die Instruktionsleistung oder die Effizienz der Software oder des Programmierers - mit, aber Mips sind eben schön zu messen, griffig in der Argumentation und scheinbar gut zu vergleichen.
Der Haken ist nur, daß die Hersteller bei der Angabe der Mips ihrer Systeme mehr oder weniger mogeln oder sogar mogeln müssen: Wer keine Gleitkomma-Hardware hat, läßt diese Befehle deshalb einfach weg, und schon sind die Zahlen wieder gesund. Oder: wie soll man eine Fortran-Library im Microcode hier einfließen lassen? Die Mips-Zahlen würden dann schlechter werden. Wie
fließt eine Gleitkomma-Genauigkeit von 128 Bit in dieses Zahlenspiel ein?
Hat beispielsweise eine Maschine nur sehr schwache, aber dafür schnelle Befehle, wie vielleicht nur BRANCH ON POSITIV, so muß man für die kleinste Alternative immer ein ganzes Programm ablaufen lassen. Wenn dagegen eine andere Maschine für diesen Befehlstyp eine ganze Palette von Variationsmöglichkeiten bietet, sodaß man meistens mit einem einzigen Befehl hinkommt, wird der einzelne Befehl natürlich etwas langsamer, die wirkliche Leistung kann aber erheblich höher sein.
Lästig sind häufig auch Byte-Manipulation, Gleitkomma höherer Genauigkeit oder bedingte Verzweigung. Eine sehr häufig praktizierte und nie sichtbar gemachte Variante.
Hersteller lassen daher meistens Befehle, die ungünstig für griffige Mips-Zahlen sind, bei der Berechnung einfach weg und kommen so zu schönen Zahlen, bei denen die wirkliche Leistungsfähigkeit untergeht (wie bei Floating Point Quadruple Precision, oder Programmlibraries im Microcode), weil dies nur noch mehr zum Verwirrspiel beitragen würde, oder es fallen intelligente Branch-Befehle unter den Tisch (wie bei manchen großen Zahlen-Crunchern) und es kommen ungeheuer beeindruckende "Mipse" heraus.
Die Schwäche dieser Struktur der "ersten Art" wird dann sichtbar, wenn gleichzeitig mit der Verarbeitung auch noch Rechenleistung verlangt wird. Die Zentraleinheit kann sich nicht ohne weiteres zweiteilen, kann also nur entweder den einen oder den anderen bedienen. Das mag nicht direkt sichtbar sein, denn ein gutes Betriebssystem kann die Verteilung dieser Verfügbarkeit recht intelligent bewerkstelligen, aber im Grundsatz ändert das nichts.
Negatives Beispiel für solche Anwendungen ist der Time Sharing Bereich (Terminals, Plattenzugriffe, Drucker, und der Benutzer selbst will ja auch noch etwas vom Computer erledigt haben).
Ein anderes negatives Beispiel für diese Rechenstruktur ist die Prozeßsteuerung: Meßdaten werden erfaßt und der Rechner hat genau dann die höchste Rechenleistung zu vollbringen, wenn die Datenrate am höchsten ist. Diese Art von Rechner ist dann aber sehr schnell am Ende.
Hier haben solche CPU-Centered Systeme meistens ihre Grenzen. Es werden dann mit technischen Tricks diese Grenzen hinausgeschoben, aber nicht beseitigt. Eine Verbesserung der Leistungsfähigkeit bei anspruchsvolleren Systemen ist nur durch eine Änderung der Architektur zu erreichen.
Legt man nicht mehr die Zentraleinheit ins Zentrum des Systems, sondern (mindestens) einen Datenbus, an den die Systemkomponenten angeschlossen werden, dann läßt sich schon eine gewisse Leistungssteigerung und größere Unabhängigkeit von Konflikten innerhalb des Systems erreichen. Über einen Kabelstrang kann man halt mehr Bytes pro Zeiteinheit jagen als durch einen komplexen Computer.
Nur ist hier das Problem, daß viele Geräte, wenn sie einmal Zugang zu einem solchen Bus haben, ihn einfach nicht mehr loslassen. Damit ist der Vorteil des Busses nur dann gegeben, wenn die Peripherie ihn auch wieder freigibt.
Da die Zentraleinheit hierdurch erheblich beeinträchtigt werden kann, findet man in solchen Systemen häufig Pufferspeicher (Cache Memory), die zwischengeschaltet werden, damit wenigstens solche Speicherinhalte noch mit vernünftiger Leistung abgearbeitet werden können, die in aufeinanderfolgender Reihe abgespeichert werden. Pech hat man allerdings, wenn ein Programm in intelligenter Weise oft verzweigt, sodaß die nächste geforderte Adresse dann eben wieder nicht im Puffer liegt und erst ein neuer Pufferblock ausgelesen werden muß. Solche Puffer sind also nicht ganz sinnlos, aber bei vielen Anwendungen in ihrer Auswirkung fraglich oder in Einzelfällen sogar negativ. Aber Benchmarks lassen sich mit etwas Geschick sehr schön programmieren, damit die Ergebnisse stimmen!
Was aber allzuhäufig bleibt, sind Konflikte auf dem Bus, der ja durch Cache und Bus-Sharing sehr hohe Volumina an Daten zu verkraften hat, einschließlich aller Daten, die den Datenstrom steuern müssen; schließlich muß der Hauptspeicher wissen und zusätzlich zu den zu verarbeitenden Daten gesagt bekommen, wann er gemeint ist, wieviel Bytes/Worte an Daten jetzt abzufangen sind, wann er nicht gemeint ist, ob der Bus im Burst oder im Multiplexer Mode arbeitet.
Wenn auch das nicht reicht, sieht man häufig, daß dann eben ein zweiter Bus parallel geschaltet wird. Viel hilft viel, scheint manchmal die Devise zu sein. Man kompensiert also den Schwachpunkt durch ein Pflästerchen, das wiederum Schwachpunkte hat.
Systeme dieser Art sind auf jeden Fall erheblich leistungsstärker als Systeme der "ersten Art". Wenn dies noch mit hoher Mips-Leistung gekoppelt ist, ist der typische Anwendungsfall das kleine Time Sharing System (zum Beispiel einer Universität, aber mit nicht zu vielen gleichzeitig aktiven Terminals!), einfache bis mittlere Steuerungsaufgaben (Labor-Datenerfassung) und natürlich die traditionelle Batch-Verarbeitung. Hohe Mips-Raten und die Bus-Kapazität plus Cache-Anforderungen beißen sich allerdings manchmal, sodaß auch hier schnell Grenzen gesetzt sind.
Diese Art von Systemen werden sogar kräftig überfordert, wenn größere Datenakquisitions- und Simulationsaufgaben anstehen. Man kann einem U-Bahn-System oder einem Testpiloten schlecht antragen, er solle etwas langsamer machen, weil der Rechner mit der Überwachung nicht nachkomme. Für solche Anforderungen benötigt man ein System, bei dem die Rechnerleistung auch bei höchster zu verarbeitender Datenfrequenz nicht reduziert wird. Das wiederum ist nur mit einer ganz anders gearteten Rechnerstruktur erreichbar, der Architektur der "dritten Art".
Dies sind die sogenannten "Memory Centered" Systeme. Im Mittelpunkt steht ein intelligenter Hauptspeicher, an den sowohl der oder die Zentralrechner und die Ein/Ausgabeeinheiten radikal angeschlossen sind.
Von Vorteil sind solche Strukturen immer dann, wenn hohe Datenraten und gleichzeitig unbehinderte Rechnerleistung gefordert werden. Dies sind: Prozeß-Steuerung (wie Stromversorgungsnetze, Simulatoren, Walzwerksteuerung), große Time-Sharing Systeme mit vielen Außenstellen, Krankenhäuser, Universitäten, Service-Büros,) bei denen die Antwortzeiten kurz sein müssen.
Fail-Safe beziehungsweise Non-Stop-Systeme lassen sich mit solchen Hardware-Strukturen ebenfalls eleganter und problemloser lösen als mit den beiden vorher genannten Konzepten.
Ein Memory-Centered-System kann beispielsweise so aufgebaut sein:
Der Speicher im Zentrum hat mehrere Eingänge, sogenannte Ports, mindestens einen pro radial angeschlossener Einheit. Maximal zwölf Ports kann ein Zentralspeicher haben. Bis zu vier Speicherbänke (overlapp) und maximal 32 Megabyte pro Einheit. Cache-Speicher und ähnliche Dinge sind nicht vorhanden, da solche Hilfsmittel in dieser Struktur sinnlos sind. Dagegen ist ein 56-Bit breiter Microcode-Speicher vorhanden, um Kompatibilitäten herzustellen, Flexibilität und Zukunftssicherheit zu sichern und um häufig genutzte Programme (wie Fortran-Libraries) aufzunehmen.
Die Bandbreite des Speichers liegt bei 32 Bit Datenbreite je nach Ausbau zwischen 10 und 40 Megabyte. Vergleicht man dies mit der Datenrate einer Magnetplatte, die vielleicht 1,2 Megabyte pro Sekunde überträgt, mit einem Band (800 Kilobyte) oder mit einem Terminal (920 Byte pro Sekunde), dann wird klar, daß hier für die Zentraleinheit ziemlich viel übrig bleibt, ehe einmal ein Konfliktfall eintreten könnte.
Nicht gerade billig
Die peripheren Einheiten selbst (eine CPU ist in diesem Falle ebenfalls eine periphere Einheit, genau so wie ein MIOP = Multiplexed I/O Processor) haben zwei unabhängige Datenkanäle in Richtung Hauptspeicher. Damit lassen sich in einem Simplex-System (eine bis vier Rechnereinheiten am gleichen Hauptspeicher sind das derzeit sinnvoll Maximale in einem solchen Simplex-System) interessante Strukturen aufbauen, wie vom Betriebssystem optimierte Dual-Access Pfade; in einem Duplex-System dagegen läßt sich sogar ein völliges Back-up aufbauen, wie Einspeisung von Communication-Trunks bei großen Message Switching Systemen in beide Rechnersysteme zur vollen Duplexverarbeitung. Und all dies wird von existierender Software und Betriebssystemen unterstützt.
Die peripheren Einheiten können zusätzlich über einen "Ringkanal" miteinander kommunizieren, der ebenfalls doppelt ausgelegt ist. Es ist offensichtlich, daß hier eine völlig andere Verarbeitungsqualität vorliegt als bei einem busorientierten System.
Durch diese Architektur wird es auch möglich, Besonderheiten einzubauen, die zu erstaunlichen Ergebnissen führen können. Das wirkt sich zwar im reinen "Boxen-Vergleich" negativ auf den Preis aus, aber ein solches Memory-Centered-System ist sowieso nicht für Feld-Wald-und-Wiesen-Anwendungen gedacht. Solche Systeme sind nicht Spar-Systeme, sondern werden dann eingesetzt wenn normale Systeme es nicht mehr schaffen.
Damit entsteht natürlich für den Erstbenutzer ein Problem bei der Systemauswahl! Memory-Centered-Computersysteme sind weitgehend unbekannt und nicht gerade auf der billigen Seite. Es sind keine Systeme für den Massenmarkt, denn sie sind dafür zu aufwendig gebaut. Typische Hersteller solcher Systeme waren DEC mit dem System 10, Xerox mit der 32 Bit Sigma-Serie und CII (Lizenz Xerox). Nachdem Xerox sich 1976 aus dem Markt zurückgezogen hatte, war der Markt etwas verwaist. DEC ließ die 10 auslaufen. Ein Nachfolger oder eine Alternative gab es erst einmal nicht. In USA dominiert bei solchen Anwendungen immer noch die zwischenzeitlich urtümliche Sigma-9. Wie sich kürzlich herausstellte, gibt es bei bestimmten Firmen heute ernsthaft Überlegungen, solche Sigma-9 Systeme in Kältekammern "einzufrieren", um längerfristig die Möglichkeit dieser speziellen Rechner zur Verfügung zu haben.
So ist im amerikanischen Markt das Paradoxon zu beobachten, daß acht Jahre nach dem Ende der Xerox-Sigma-Serie immer noch Sigma-9 Rechner original(!) nachgebaut werden weil der Ersatz einer solchen Anlage durch einen in der Mips-Rate viel stärkeren Super-Mini häufig zu katastrophalen Leistungseinbrüchen geführt hat, die auch bei Aufstockung auf bis zu sechs solcher Super-Minis im Parallelbetrieb immer noch nicht den Datendurchsatz bringen, den eine einzige Sigma-9 mit viel schlechterer Mips-Rate gebracht hat.
Aus diesem Grunde hat sich die Telefile Computer Products aus Irvine/ Californien und Niederlassung in München mit der Weiterentwicklung dieser Sigma-9-Computer befaßt.
Die amerikanische Regierung, die der wohl größte Benutzer von Computeranlagen in der Welt ist, die im Bereich der Raumfahrt und des Militärs gerade Real-Time Aufgaben komplexester Art zu bearbeiten hat, hat das Problem der Systemauswahl und damit der Beurteilung der vorgenannten Kriterien in höchstem Maße. Benchmark Tests beurteilen fast ausschließlich die reine Rechnerleistung, den "Throughput". Die Literatur ist voll von Beispielen, wo Systeme in Benchmarks hervorragend abschnitten, in der Praxis dann jedoch miserabel abschnitten.
Das Problem liegt in der exakten Definition und Simulation der tatsächlichen zu fordernden Leistung, gerade für neue Installationen, neue Anwendungen und bei Systemen mit vielen interaktiven Benutzern.
Um dieses Problem besser in den Griff zu bekommen, hat die US-Regierung (Federal Procurement Regulation (FPR) No. 1-14.11) jetzt einen Standard entwickelt, der hier mehr Klarheit schaffen soll. Eine US-Veröffentlichung gibt ein interessantes Beispiel der sich aus dieser "Regulation" ergebenden "Response time Degradation" das heißt bezüglich des Leistungsabfalles typischer Systeme, verursacht durch die Anzahl der interaktiven Benutzer. Danach ist bei herkömmlichen Systemen der Leistungsknick bei 12 bis 30 Benutzern, während er bei Memory-Centered-Systems erst bei 60 liegt.
Realtime-Anwendungen sind der typische Markt für solche "Computer der dritten Art". Sie erfordern extrem kurze Context-Switching-Zeiten, das heißt, die Umschaltzeit zwischen zwei Jobs muß extrem kurz sein.
Auch hier erlebt man mangels definierter Standards wilde Aussagen über die erreichbaren Zeiten von Systemen. Beispiel: Es ist schon ein Unterschied, ob man als Umschaltzeit angibt, wann ein Interrupt erkannt wird, oder wann das andere Programm zu laufen beginnt, oder wann alle Register ausgewechselt und damit das eigentliche Benutzerprogramm gestartet wird. Bei ein und demselben System kann man also hören, daß diese Context-Switching-Zeit 60 Mikrosekunden dauert, muß dann aber feststellen, daß der andere Job erst nach 300 Millisekunden begonnen wird, weil das Betriebssystem vorher erst noch einiges organisieren muß! Das leidige Problem mit fehlenden Definitionen läßt hier alle Tore zu jedem Bluff offen, ohne daß sogar gelogen werden muß.
Ein typisches System "der dritten Art" hat im Gegensatz zu Switching-Zeiten von 300 Millisekunden bei einem Supermini (der alles per Software organisieren muß!) eine totale Umschaltzeit von 14 Mikrosekunden, ist hier also etwa 20 000mal schneller als ein vergleichbares System der zweiten Art". Daß sich dies auf die System-Degradation auswirkt, wenn viele Benutzer interaktiv arbeiten, ist einleuchtend. Da hilft dann auch nicht, wenn die Mips-Rate doppelt so hoch sein soll.
Wie entsteht nun dieser Unterschied. Normale Systeme haben zwar auch Interrupts, aber per Software wird das House-Keeping gemacht, das heißt, die Prioritäten verwaltet, die Register des unterbrochenen Jobs gerettet, die Register des neuen Jobs geladen etc.
Ein Memory-Centered-System dagegen verwaltet die Interrupts rein per Hardware (das Betriebssystem stellt hierzu lediglich zu Beginn oder bei Bedarf die Parameter zur Verfügung), tauscht die Register aus etc. Das ist zwar aufwendig in der Elektronik, aber wenn die Prioritätsdefinitionen dies erlauben, ist ein durch einen Interrupt angestoßener Job innerhalb von 14 Mikrosekunden up-and-running, als sei er nie unterbrochen worden.
Noch ein Beispiel an Konsequenzen dieser Struktur, der sogenannten Mission Mode: In Realtime-Anwendungen darf es nicht vorkommen, daß der Rechner kritische Dinge nicht mehr zu Ende führt, weil ein Teil der Anlage oder das Betriebssystem zusammenbricht Eine U-Bahn muß eben zum Stehen gebracht werden, der Testflug bis zum Schluß überwacht werden Eine vom Computer gesteuerte Rakete muß bis zum Schluß unter Kontrolle bleiben, denn solche Testschüsse kosten Millionen. Ein Memory-Centered-System stellt diese "Mission Mode" sicher, da durch die komplexe Interrupt-Steuerung und die Unabhängigkeit der Peripherie von der Zentraleinheit eine "Mission" zu Ende geführt werden kann, egal, ob das Betriebssystem abgestürzt ist oder ein Teil der Anlage ausfällt. Das ist nicht Theorie, sondern Praxis. Bei einem traditionellen System allerdings undenkbar. Dort gilt: Down ist down!!
Ein anderes Beispiel aus der Konsequenz einer solchen Struktur sind Fail-Safe-Systeme (falls es so etwas überhaupt gibt; auf Deutsch heißt das ja auch etwas ehrlicher "fehlertolerante Systeme" ). Normale Systeme dieser Klasse arbeiten mit relativ billigen und dafür vielen parallelen Rechnereinheiten, deren Fail-Safe sich dann aus einer hochkomplexen Software ergibt. Nur ist das Problem, daß man sich im Labor die unmöglichsten Fehlerbedingungen ausdenken und dafür Recoveries schreiben kann; in der Praxis passieren dann ganz andere Fehler!
Fehlertolerant schon bei einer Zentraleinheit
Da kann es passieren, daß bei einem renommierten Fail-Safe-System das ganze System zusammenbricht, weil jemand eine nicht benutzte Platteneinheit ausgeschaltet hat. Oder eine andere Konsequenz ist, daß aufgrund der einfachen Hardware und komplexen Software ein Disk-Backup sechs Stunden dauert, wenn dies auch in 15 Minuten zu erledigen ist. Wohlgemerkt, hier handelt es sich um vergleichbare Systemklassen (vom Preis her). Weiter setzt ein solches auf Software aufbauendes System voraus, daß der Benutzer unter seiner Kontrolle sogenannte Wiederaufsetzpunkte einbaut. Es muß aber auch einmal ausgesprochen werden, daß selbst erfahrene Programmierer hier ihre Schwierigkeiten haben, geschweige denn ein normaler Anwendungsprogrammierer.
Anders ist das bei Memory-Centered-Systemen. Bereits bei einem System mit nur einer CPU (C sollte man hier streichen!) ist eine Quosi-Fail-Safe-Betriebsart möglich. Dies geht so vor sich: Angenommen, die (C)PU entdeckt einen Non-recoverable-Fehler. Per Hardware werden dann alle Register in den Speicher geworfen, die Maschine abgeschaltet, wieder neu gestartet und mit dem gleichen Befehl weitergemacht, bei dem der Fehler passiert ist. Unrecoverable bleibt dann eigentlich nur, wenn der Fehler mitten in einem langen Multiply beispielsweise passiert ist; bisher sind dem Autor erst zwei Fälle bekannt geworden, bei denen hierdurch ein Recovery nicht mehr möglich war.
Ein argumentativ angreifbarer Schwachpunkt dieser Struktur ist hier offensichtlich das Memory selbst. Aber da kann man vorbauen. Der Speicher selbst ist praktisch nie der Verursacher. Schwerer wiegt da schon ein Fehler im Netzteil, der doch schon einmal vorkommt. Dagegen hilft wiederum ein doppeltes Netzteil und Batteriepuffer, also einfacher Mehraufwand.
Noch besser wird das Bild, wenn ein Memory-Centered-System aus mehr als einer (C)PU besteht. Da nicht wie bei einem Bus-System in master-slave-mode gearbeitet werden muß (Konsequenz: die zweite CPU bringt nicht nur 30 Prozent, sondern fast 100 Prozent mehr Systemleistung), kann jede (C)PU gleichrangig arbeiten. Wird dies mit einem Betriebssystem kombiniert, das sogenanntes "anonymous processing" bedient (jeder Job kann auf jeder (C)PU laufen, wird vom Betriebssystem nach der jeweiligen Priorität zugeteilt), dann passiert bei einem erkannten Fehler folgendes: Die erkennende Maschine wirft per Hardware alle Register in den Zentralspeicher, signalisiert der zweiten (oder den anderen) (C)PUs, daß ein Problem vorliegt und verabschiedet sich, nicht ohne vorher eine weithin sichtbare Warnlampe in Aktion zu setzen.
Die nächste freie (C)PU greift dann (wieder Hardware-gesteuert) den Interrupt auf und setzt das Programm mit dem Befehl fort, mit dem die erste Maschine nicht weiter konnte. Damit sind selbst schwerwiegendste Systemfehler korrigierbar, ohne daß der Benutzer aber auch nur einen einzigen "Fail-Safe"-Befehl zu schreiben hätte!
Daß zur Ausnutzung derartiger Struktur-Leistung ausgefeilte Betriebssysteme gehören, ist selbstverständlich. Xerox hat bei seinem Ausstieg aus dem Computermarkt ein Betriebssystem (CP-V) hinterlassen, das eine Investition von rund 100 Millionen Dollar darstellt und von Telefile weiterentwickelt wurde (TCP-V LVM mit Anonymous Processing).
Wie soll der Kunde nun urteilen, wenn die Verkäufer ihm immer nur die Sonnenseite der jeweiligen Systeme vorhalten? Ein Rezept gibt es nicht. Jede Art von Computer-Architektur hat eine Berechtigung. Es hilft nur
- gut zuhören, und dann den gesunden Menschenverstand verwenden;
- nicht in die Falle laufen, daß das, was alle machen, auch für die eigenen Probleme richtig sein müsse;
- die Mühe auf sich nehmen und das eigene Problem genau definieren. Das ist zwar mühsam, aber es ist der Schlüssel zu einer guten Lösung.
- den Mut haben, nicht der Masse nachzulaufen. Es sollte gegen die persönliche Ehre gehen, sich den Spruch sagen lassen zu müssen: "In der Masse stirbt sich's leichter."