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.

17.04.1987 - 

Schnelle Vektorpipelines sind oft schlecht ausgelastet:

Langsame Speicher behindern Jumbo-Leistung

FRANKFURT - Im Hinblick auf die Anforderungen an Supercomputer haben sich die Gewichte drastisch verschoben. Schon seit geraumer Zeit entscheidet hier nicht mehr das Vorhandensein von Vektorinstruktionen über das Sein oder Nichtsein. Die zu knackende harte Nuß besteht heute für die Entwickler der Rechner-Jumbos darin, die Speicher gegenüber den Pipeline-Geschwindigkeiten "auf Trab zu bringen" und die richtige Balance zwischen diesen beiden Komponenten herzustellen.

Noch vor ein paar Jahren war es einfach, zu entscheiden, was einen Supercomputer ausmachte. Ein Rechner, der Vektor-Instruktionen bot, war Supercomputer, einer ohne nur Computer. Heute ist die Auswahl schwieriger. Fast jeder Universalrechner bietet Vektor-Instruktionen, ein moderner Supermini wird mit ihnen zum Minisuper, und der Kampf um die MFlops macht auch vor den Arbeitsplatzrechnern nicht halt. Ein "Warrior"-Board (oder auch ein anderes) in den 68020 PC gesteckt, läßt die CDC 7600 im Rechenzentrum und womöglich die Cray 1 daneben im wahrsten Sinne des Wortes alt aussehen. Wenn also die Vektor-Instruktionen so langsam zur Serienausstattung eines Computers werden, was zeichnet dann 1987 einen Supercomputer aus?

Supercomputer der jetzigen Generation, die oft auch Supercomputer der Klasse VI genannt werden, waren so erfolgreich, weil mit der Idee, gleiche Rechenoperationen in einer Hardware-Instruktion abzuarbeiten, eine neue Schwelle an Rechenleistung überwunden wurde. Oberhalb dieser Schwelle können einigermaßen realistische Modelle aus den Natur- und Ingenieurwissenschaften mit digitalen Rechnern numerisch simuliert werden. In der Tat hat sich auf Grund dieser neuen Größenordnung an Rechenleistung eine neue wissenschaftliche Disziplin zwischen Theorie und Experiment etabliert.

Die "computational sciences" auf der einen und die rechnergestützte Ingenieurwissenschaften auf der anderen Seite waren die treibenden Kräfte - auch in einem kommerziellen Sinn - hinter der Entwicklung und Weiterentwicklung der Klasse-VI-Supercomputer. Die Anforderungen dieser Disziplin bestimmen auch die Entwicklung der neuen Generation von Supercomputern.

Rennen um Nanosekunden

Diese neue Größenordnung der Rechenleistung wurde aufgrund einer neuen Rechnerarchitektur möglich, ohne daß dazu ein Fortschritt in der Hardware-Technologie notwendig war. Nachdem die grundlegende Idee der Vektor-Instruktionen in der Cray 1 und Cyber 205 ihre kommerzielle Verwirklichung gefunden hatte, verlief die weitere Entwicklung der Klasse-VI-Rechner wieder in mehr konventionellen Bahnen. Wie bei den Universalrechnern auch gab es Verbesserungen der Architektur im Detail. Im wesentlichen mußten sich die Hersteller jedoch damit zufriedengeben, die Taktzeit der Rechner zu verbessern, um zu höheren Leistungen zu gelangen. Da die Taktzeit eines Vektorrechners umgekehrt proportional zu seiner MFlop-Rate ist, heißt dies, daß in die CPUs immer schnellere Vektorpipes eingebaut wurden. Das Rennen um die Nanosekunden wurde sogar so weit getrieben, daß die CPU wieder mit weniger Logik ausgestattet wurde (zum Beispiel Wegfall von Chaining), nur um die Taktzeit klein halten zu können. Im Zuge dieser Entwicklung wird es immer schwieriger, die schnellen Vektorpipes mit Daten zu versorgen, da die Zugriffszeiten auf den Hauptspeicher bei wachsenden Anforderungen an die Speichergröße nicht genügend verkürzt werden können. Die CPU wird somit vom Hauptspeicher mehr und mehr isoliert.

Kürzere Taktzeit bringt mitunter nichts

Bringt diese Entwicklung die Anwendungen in den computergestützten Natur- und Ingenieurwissenschaften weiter? In der Tat nicht. Schon bei den ersten Supercomputern mit relativ langen Taktzeiten wird die Geschwindigkeit der Vektorpipes in einer größeren Anwendung bei weitem nicht ausgeschöpft. Besonders Programme aus den Ingenieurwissenschaften, die in der Regel von Universalrechnern auf die Supercomputer portiert werden, erreichen oft nicht einmal 10 Prozent der Pipegeschwindigkeit, wenn man MFlop pro Sekunde CPU-Zeit über die ganze Anwendung betrachtet. Macht man die Vektorpipe durch Verkürzung der Taktzeit noch schneller, so gewinnt eine solche Anwendung dadurch überhaupt nichts. Betrachtet man aber MFlop pro Sekunde Verweilzeit - und nur das ist die Maßzahl, die den Ingenieur interessiert und den Rechenzentrumsleiter, dessen Anlage eben dieser Ingenieur blockiert -, so wird das Bild noch viel schlechter. Eine Auslastung der Vektorpipes von wenigen Prozent ist dann die Regel, und es ist noch unsinniger, die Pipes schneller zu machen.

Aus dieser Tatsache lassen sich richtige und falsche Schlüsse ziehen. Ein falscher Schluß ist, daß es mit langsamen Vektorpipes in einem Universalrechner bei vielen Anwendungen gelingen müßte, die Leistung eines echten Supercomputers zu erreichen. Die schwache Auslastung der schnellen Pipes liegt nämlich in aller Regel nicht daran, daß in den großen Ansendungen die skalaren Operationen überwiegen würden oder auch nur einen bedeutenden Anteil hätten. Skalare Operationen sind in einem Anwendungsprogramm in der Regel nur in der Initialisierungsphase wichtig und bei der Ergebnisaufbereitung, also in der Phase eines Programmes, wo eine technische Aufgabenstellung in eine mathematische umtransformiert wird. Im eigentlichen Lösungsteil dominieren Vektor-Instruktionen. In der Tat gibt es selbst unter den Anwendungsprogrammen, die von Universalrechnern portiert wurden, nur wenige, bei denen man nicht mit endlichem Aufwand einen Vektorisierungsgrad von über 90 Prozent erreichen kann. Und bei Programmen, die für Vektorrechner konzipiert sind, ist ein Vektorisierungsgrad von mehr als 93 Prozent selbstverständlich.

Hoher Vektorisierungsgrad oft nur schwer erreichbar

Zur Illustration dieses Sachverhaltes, der oft verkannt wird, ein kleines Beispiel aus der Praxis. Nehmen wir einmal an, daß in einem Anwendungsprogramm für einen Klasse-IV-Supercomputer der Lösungskern 100 000mal durchlaufen wird. Das zu bearbeitende Problem mag dabei in einem 50x50x50-Gitter dargestellt sein. Erhöht man die Anzahl der Gitterpunkte in jeder Raumdimension nur um den Faktor 2, so muß der Lösungskern bereits 800 000mal durchlaufen werden. Falls die Initialisierung und Ergebnisaufbereitung beim kleinen Problem noch einen Anteil von 30 Prozent hatten, so tragen sie beim größeren Problem nur noch mit 4 Prozent bei. Geht man aber auf ein 500x500x500-Gitter über - und eine solche Auflösung ist notwendig, um eine technische Aufgabe im Detail darstellen zu können -, so beträgt der nicht vektorisierte Anteil gerade noch 0,03 Prozent.

Schnelle Pipes warten auf Daten

Die schnellen Vektorpipes in einem Supercomputer sind bei einer großen Anwendung in der Regel deshalb schlecht ausgelastet, weil sie nicht ausreichend schnell mit Daten versorgt werden können. Dies liegt manchmal am Programm. Insbesondere bei den Programmen, die aus der Zeiten der kleinen Hauptspeicher stammen, haben die Programmierer viel Genialität in eine Datenorganisation gesteckt, die für die Vektorrechner gänzlich ungeeignet ist. Wenn das Problem der Datenorganisation jedoch befriedigend gelöst ist, so sind die Pipes meist trotzdem noch leer. Um sie nämlich kontinuierlich in Betrieb zu halten, müßten gerade bei einer geeigneten Datenorganisation die Hauptspeicher der Supercomputer um ein Vielfaches größer sein.

Größere Speicher nötig

Damit stoßen wir an eine Grenze der Supercomputer der Klasse VI, die die Anwendungsmöglichkeiten dieser Rechner stark einschränkt. Die schnellen Vektorpipes dieser Rechner können in der Regel nicht ausgelastet werden, da die verfügbaren Hauptspeicher zu klein sind. Genau an diesem Punkt muß die Entwicklung einer neuen Generation von Supercomputern ansetzen. Gelingt nämlich eine Änderung der Architektur in der Weise, daß die Geschwindigkeit die Vektorpipes in einen Anwendung voll ausgenutzt werden kann, so erreicht man wieder eine neue Größenordnung an Rechenleistung, ohne daß die Taktzeit der Supercomputer verkürzt werden muß.

Warum kann man das Architekturproblem der Klasse-VI-Rechner nicht einfach dadurch lösen, daß man sie mit viel größeren Hauptspeichern versieht? Der Grund liegt in der Technologie von Speicherbausteinen. Schnelle Halbleiterspeicher haben keine ausreichende Packungsdichte; solche mit genügend hoher Integrationsdichte sind nicht ausreichend schnell. Mit den wachsenden Anforderungen an die Hauptspeichergröße kann die Technologie nicht mithalten. Ein Hauptspeicher, der mehrere hundert Millionen Worte groß ist, erlaubt mit heutiger Technologie keine Zugriffszeiten, mit der eine Vektorpipe von mehr als hundert MFlops versorgt werden kann. Auch die seit langem angewandte Technik, den Hauptspeicher in unabhängige Bänke aufzuteilen, aus denen überlappt gelesen wird, reicht nicht aus um die Kluft zwischen langsamen Speicherbausteinen und schnellen arithmetischen Einheiten zu überbrücken. Die Schere zwischen Pipegeschwindigkeit, Hauptspeichergröße und Bankkonflikten klafft zunehmend auseinander.

Eine gewisse Abhilfe bei dem Problem schaffen Erweiterungsspeicher. Diese Idee wurde erstmals bei der CDC6600 unter dem Namen "Extended Core Storage" kommerziell verwirklicht und ist danach in verschiedenen Abwandlungen entweder als echte Hauptspeichererweiterung transparent für den Benutzer oder als Halbleiterplatte in andere Rechnerarchitekturen eingeflossen. Der große Erweiterungsspeicher allein löst das Problem der leeren Pipes jedoch auch nicht, denn er ist zu langsam, um mit der Pipegeschwindigkeit mitzuhalten. Erst die geschickte Kombination von Hauptspeicher und Erweiterungsspeicher wird es möglich machen, die schnellen Vektorpipes der Klasse-VI-Supercomputer auch wirklich auszunutzen. Eine neue Generation von Supercomputern braucht deshalb eine neue Speicherarchitektur.

Gegliederte Hierarchie mit spezifischen Aufgaben

Bei den neuen Supercomputern hat man sich mit diesen Fragen ausführlich auseinandergesetzt. Das Ergebnis ist ein Supercomputer, bei dem die Idee des Multiprocessing mit einer ausgewogenen Speicherhierarchie verbunden wird, um so den Anforderungen nach großen Speichern und schnellen arithmetischen Einheiten gerecht zu werden. Bei den ETA-10-Supercomputern wird von der herkömmlichen Speicherarchitektur grundlegend abgewichen. Bei diesen Rechnern gibt es keinen "Haupt"-Speicher mit untergeordneten Caches und Erweiterungsspeichern mehr, sondern es wurde eine funktional gegliederte Hierarchie von Speichern mit spezifisch zugeordneten Aufgaben aufgebaut. Es gibt Skalar- und Vektorregister, lokale Speicher (Local Memory) und gemeinsame Speicher (Shared Memory und Communications Buffer). Register und Local Memory stehen einer CPU alleine zur Verfügung und werden von dieser verwaltet. Auf Shared Memory und Communications Buffer greifen mehrere CPUs zu. Diese gemeinsamen Speicher werden von einer eigenen Logistik verwaltet, die von den CPUs getrennt ist.

Shared Memory für Prozeß-Kommunikation

Local Memory hat dabei alle Funktionell eines Hauptspeichers für eine einzelne CPU, Shared Memory die Funktionen eines Hauptspeichers für das Mehrprozessorsystem als Grenze, und der Communication Buffer übernimmt die Synchronisation zwischen den CPUs. Insbesondere können darin sogenannte Semaphores abgeleitet werden, mit denen eine CPU den anderen den Beginn oder das Ende eines Prozesses mitteilen kann. Auch Shared Memory spielt bei der Kommunikation zwischen Prozessen eine wichtige Rolle und ist weit mehr als nur ein Erweiterungsspeicher für Local Memory zur Ablage von gerade nicht benötigten Hauptspeicherseiten. Shared Memory erlaubt über die Definition von Windows den Zugriff auf beliebige, mehrdimensionale Speichergebiete von mehreren CPUs aus. Dabei kann eine CPU das Recht haben, Shared Memory zu verändern, oder sie darf nur lesen.

Multiprocessing auf einer ETA-10 beispielsweise ist in diesem Sinn der Versuch, die auseinanderklaffenden Ansprüche der Benutzer zwischen schnellen Vektorpipes und ebenso schnellen, großen Hauptspeichern wieder Zusammenbringen. Dagegen wird bei anderen Rechnerarchitekturen, insbesondere bei massiv parallelen Architekturen, Multiprocessing als ein Weg gesehen, um zu mehr CPU-Leistung zu kommen. Die CPU-Leistung eines ETA-Supercomputers reicht aus. Wollte man tatsächlich mehr MFlops erzielen, so wäre es sehr einfach, die arithmetischen Einheiten stärker zu segmentieren, und zu kürzeren Taktzeiten zu kommen.

Sieht man Multiprocessing als einen Weg, um hohe Pipegeschwindigkeiten mit ausreichend viel und ausreichend schnellen Hauptspeichern zu balancieren, so entgeht man einer großen Gefahr der Parallelverarbeitung. Verteilt man nämlich ein Programm auf mehrere Prozessoren, um die CPU-Zeit zu verteilen, so verbraucht es in der Summe immer mehr CPU-Zeit als auf einem Prozessor. Verteilt man dagegen ein Programm auf mehrere Prozessoren, weil es mehr Hauptspeicher braucht, so nimm es insgesamt weniger Ressourcen in Anspruch als auf einem Prozessor, da der gesamte I/O-Overhead wegfällt.

Neue Schwelle der Rechenleistung

Durch die Balance der verschiedenen Speicher in der Speicherhierarchie wird es auch bei sehr großen Anwendungen gelingen, die hohe Geschwindigkeit einer Vektorpipe voll auszunutzen. Damit überschreiten diese Supercomputer eine neue Schwelle der Rechenleistung und stoßen sowohl zu einer neuen Qualität der Supercomputer-Anwendungen wie auch zu einer neuen Generation von Supercomputern das Tor auf.

*Wolfgang Bez ist Leiter der Zentralgruppe Anwendungssoftware für Supercomputer bei der Frankfurter Control Data GmbH.