Die Anwender sind bequem geworden: Sie sind immer weniger bereit, die gewünschte Leistung mühsam und von Hand aus ihrem Computer herauszukitzeln. Den von PCs und Workstations gewohnten Komfort erwarten sie inzwischen auch vom Supercomputer. Welche Probleme sich daraus ergeben und wie die Hersteller der "zahlenfressenden Monster" sich darauf einstellen, erläutert Frank Baetke*.
Supercomputer sind im Bereich der Ingenieurwissenschaften wie auch der Naturwissenschaften zum unentbehrlichen Hilfsmittel geworden. Ursprünglich nur für einen exklusiven Kreis von Wissenschaftlern gedacht, wurde ihre extrem Supercomputer zum unverzichtbaren Werkzeug geworden.
Mit der starken Verbreiterung der Anwendungsbasis
kann immer weniger davon ausgegangen werden, daß Nutzer oder selbst Programmentwickler über spezielle Supercomputing-Kenntnisse verfügen. Folglich muß die softwaremäßig realisierte Schnittstelle, die "Benutzeroberfläche" des Supercomputers, so weit wie möglich das "Look and Feel" vermitteln, das denn Anwender von seiner gewohnten Umgebung her vertraut ist, ob es sich nun um PCs, Workstations, Minicomputer oder klassische Mainframes handelt.
Der "klassische" Einsatz eines Supercomputers erfolgte ausschließlich im Batch-Betrieb. Mittlerweile jedoch wird immer häufiger die Forderung nach einem interaktiven Zugriff erhoben, so daß zunehmend auch über grafische und fensterorientierte Oberflächen nachgedacht werden muß. Das betrifft auch die - den Anwendern und Entwicklern in der Regel nicht zu gänglichen - Schnittstellen zur Systemverwaltung, da hier die Ansatzpunkte für eine optimale hohe Rechenleistung inzwischen zur selbstverständlichen Voraussetzung bei der Entwicklung einer Vielzahl von Produkten. Für die chemische und pharmazeutische Industrie, für den Flugzeug- und Automobilbau sowie für Meteorologie und Wirtschaftswissenschaften sind Steuerung der Prozessorleistung liegen.
Im folgenden wird auf die unterschiedlichen und einander teilweise überlappenden Ansprüche der drei Benutzergruppen - Anwender, Entwickler und Systemadministratoren detaillierter eingegangen und ein Überblick über die derzeit verfügbaren Schnittstellen gegeben. Ohne Anspruch auf Vollständigkeit sollen damit auch Kriterien zur Beurteilung einer Implementierung bereitgestellt werden.
Grundlegende Standards
Supercomputer werden heute fast ausschließlich als technischwissenschaftliche Universalrechner in heterogenen Netzen betrieben, wobei sich auf konzeptioneller Ebene folgende Tatsachen feststellen lassen:
- Als Prozessorarchitektur hat sich ausschließlich die Vektorregistermaschine mit mehreren auf einen gemeinsamen Hauptspeicher zugreifenden CPUs durchgesetzt. Wie noch gezeigt wird hat dies erhebliche Konsequenzen für die Programmierschnittstelle. Die neueren, massiv parallelen Rechner sind in diesem Markt bislang nur für Spezialanwendungen von Bedeutung (wie auch das "Suprenum"-Debakel deutlich zeigte).
- Die Einbindung des Supercomputers als Server in ein heterogenes Netz mit einem Minicomputer oder einer Workstation als Client und einem unter Umständen von beiden unabhängigen Fileserver führt zur Forderung nach einem einheitlichen binären Daten- und darüberliegenden File-Format im Netz. Als Standard gilt hier eindeutig das IEEE-Format, dessen Einsatz einen völlig transparenten Zugriff auf alle binären Daten-Files im Netzwerk sichert. Auch die Hersteller "klassischer" Supercomputer können sich dieser Forderung nicht entziehen.
- Als Betriebssystem gibt es zu Unix keine Alternative mehr.
Tatsächlich war es ein Supercomputer der obersten Leistungsklasse (Cray-2), der Unix bei den Großsystemen zum Durchbruch verhalf. Da weder System-V-, OSF/1- oder die X-Open-Spezifikationen den Anforderungen von Großsystemen gerecht werden, ist bei den Systemaufrufen der Posix-Standard IEEE 1003.1 (inzwischen unter 9945-1 von der ISO übernommen) und bei den Kommandos und Utilities IEEE 1003.2 (ISO 9945-2) als Standard anzusehen (alle oben erwähnten Spezifikationen beinhalten den Posix-Standard).
Als Netzwerk-übergreifendes Batch-System hat sich das ursprünglich von der NASA entwickelte Network-Queuing-System (NQS) eindeutig durchgesetzt. Die herstellerunabhängige Standardisierung eines entsprechenden Produkts erfolgt inzwischen auch in einem Posix-Gremium (IEEE 1003.10/15).
Schnittstellen für Anwender
Batch-Anwender: Wegen der bei Supercomputer-Anwendungen typischerweise sehr langen Laufzeiten und den zuweilen GB-Dimensionen erreichenden Daten-Files wird meist der größte Teil der Systemressourcen über das Batch-System beansprucht. Die in manchen Unix-Varianten vorhandenen Befehle "at" oder "bg" (Background) sind hier völlig unzureichend. Nötig ist ein System, das:
- Job-Warteschlangen mit unterschiedlichen Prioritäten und einstellbaren Ressourcenobergrenzen zur Verfügung stellt;
- Jobs bei Überschreiten der Grenzwerte automatisch abbricht (wichtig beispielsweise für Testläufe mit noch fehlerhaften Programmen);
- transparenten Zugriff nicht nur zu lokalen, sondern auch zu "Remote-Systemen" ermöglicht und unter Umständen für eine automatische Jobverteilung zwischen unterschiedlichen Systemen sorgt;
- jederzeit Auskunft über den Zustand und die verbrauchten Ressourcen der im Netz befindlichen Jobs gibt;
- das Herausnehmen oder Umordnen von wartenden Jobs ermöglicht, um etwa bei einem frühzeitig erkannten Fehler eine Verschwendung von Ressourcen zu verhindern.
Die meisten dieser Anforderungen werden vom NQS-System erfüllt. Daneben werden an eine brauchbare Batch-Schnittstelle jedoch noch weitere Forderungen gestellt, von deren Implementierung die Standard-Unix-Systeme noch weit entfernt sind. Hierzu gehört beispielsweise die Verarbeitung von Magnetbändern mit ANSI-Kennsätzen (9-Spur-Tapes oder 3480-Kassetten) sowie die Möglichkeit, einen kompletten Job per Speicher-Dump und inklusive aller geöffneten Files und Unterprozesse zu einem beliebigen Zeitpunkt zu sichern und später wieder weiterlaufen zu lassen. Diese als "Checkpoint/Restart" bezeichnete Option muß angesichts der häufig sehr lang laufenden Supercomputer-Anwendungen als essentiell gelten, ist aber wegen ihrer hohen Komplexität nur auf wenigen Unix-Systemen zu finden. Mit ihr ist es möglich, auch bei Vollast (viele aktive Batchjobs) einen geordneten Shutdown mit späterer Fortsetzung der Arbeit durchzufahren
Schließlich ist in diesem Zusammenhang auch die Möglichkeit zu erwähnen, die Ressourcen des Supercomputers virtuell unter verschiedenen Benutzergruppen so aufzuteilen, daß, über einen gewissen Zeitraum gemittelt, jede der Gruppen ihren festgelegten Anteil erhält. So hat der Anwender die Gelegenheit, Rechenzeit "aufzusparen" und dafür später bei Bedarf mit erhöhter Priorität zu rechnen. Unter der Bezeichnung "Share" ist ein derartiges Produkt zum Beispiel unter Convex-OS verfügbar.
Interaktive Anwender: Mit der Ablösung der klassischen Batch-orientierten Betriebssysteme auf Supercomputern durch Unix-Implementierungen wurde die Möglichkeit zum interaktiven Zugriff geschaffen. Das ist speziell für die Programmentwicklung von besonderer Bedeutung, spielt aber auch bei Anwendungen eine immer größere Rolle.
Was kann der Anwender heutzutage von einem direkten Terminalzugriff (VTxx-kompatibel, 3270-kompatibel, X-kompatibel) erwarten?
- Alle Unix- und sonstigen Standard-Editoren sind verfügbar, einschließlich vi, Emacs, EDT oder TPU (DEC), mit voller
Funktionalität.
- Der Anwender kann X-Protokoll entweder im Direktzugriff über ein X-Terminal oder via Remote-Login von einer Workstation aus ansprechen, einschließlich der auf dem X-Standard basierenden grafischen Oberflächen wie etwa OSF/Motif. Letztere bestimmt in zunehmendem Maße die Anwendungsoberflächen und sollte als Benutzerschnittstelle auch auf dem Supercomputer zur Verfügung stehen.
Die zunehmende Bedeutung grafischer Oberflächen ist schließlich auch unter dem Aspekt der Visualisierung der anfallenden Daten zu sehen. Als der De-facto-Standard kann hier das ursprünglich von Stellar entwickelte System AVS (Application Visualization System) gelten, das beispielsweise über ein Colour-X-Terminal die direkte Nutzung des Supercomputers erlaubt. Ebenfalls von Bedeutung ist hier die Verfügbarkeit von PHIGS + (Programmers Hierarchical Graphic Subsystem) und PEX (PHIGS Extension to X).
Nutzung als Workstation-Server: Im Rahmen des Client-Server-Modells laufen die für den Benutzer sichtbaren Anwendungen (dialogorientierte Oberfläche, Datenaufbereitung, Vor- und Endverarbeitung) auf den Workstations, während der Supercomputer beispielsweise die Rolle des File- und Computerservers sowie des Datenmanipulators übernimmt. Auf die Bedeutung eines einheitlichen Datenformats für diesen Fall wurde bereits hingewiesen; es ermöglicht zum Beispiel, daß ein großes, auf dem Supercomputer laufendes Serverprogramm zweidimensionale Ebenen aus einer, sich in den GB-Bereich erstreckenden dreidimensionalen Datenmatrix "schneidet" und diese über einfache Schnittstellen (ohne Konvertierung) extrem schnell der Client-Software auf der Workstation (zum Beispiel AVS) verfügbar macht.
Eine derartige Aufsplittung der Applikationen in Teilbereiche minimiert erstens die Netzwerk-Last - weil die Selektion der Daten bereits auf dem Server stattfindet, so daß nur noch die wirklich benötigten Daten an die Workstation geschickt werden müssen - und erlaubt zweitens, für jede Teilaufgabe die jeweils am besten geeignete Hardwarekomponente einzusetzen. Dieses Konzept erlebte seinen Durchbruch mit Datenbank-Anwendungen, ist aber keineswegs darauf beschränkt: Das erwähnte Visualisierungspaket AVS ist ebenfalls in einer derart gesplitteten Version verfügbar.
Schnittstellen für Entwickler
Was für den interaktiv arbeitenden Anwender gilt, trifft mindestens genauso für den Entwickler zu. Neben "seinem" Editor erwartet er vor allem eine möglichst kurze Reaktionszeit seiner Entwicklungsumgebung. Speziell die Code-Optimierung, mit der man einen möglichst hohen Vektorisierungs- und Parallelisierungsgrad erreichen will, ist dadurch gekennzeichnet, daß der Zyklus "Editieren, Compilieren, Profilieren (= Performance-Analyse)" besonders häufig durchlaufen wird.
Diesen Zyklus im Batch-Betrieb zu realisieren gilt nicht mehr als zeitgemäß. Mit Hilfe von NFS etwa lassen sich Quellcodes, Bibliotheken etc. auf beliebigen File-Systemen im Netz transparent verwalten. Während das Editieren damit auf einer lokalen Workstation erfolgen kann, liegen die Tools zur Leistungskontrolle (Profiler) und Fehlersuche (Debugger) sowie die Compiler auf der eigentlichen Zielmaschine mit der entsprechenden Architektur (Vektor/Parallel).
Tools zur Leistungsmessung und Fehlersuche: Die standardmäßig unter Unix verfügbaren Tools zur Überwachung des Laufzeitverhaltens wie "prof" und "gprof" sind für den interaktiven Betrieb wenig geeignet, da sie nicht erlauben, die im Programm gesetzten Zeitmarken nach Bedarf zu aktivieren und zu deaktivieren. Gravierender ist, daß die Messung nebenläufiger (paralleler) Programmabschnitte (Threads) im allgemeinen nicht möglich ist. Ein für Supercomputer-Anwendungen taugliches modernes Tool sollte
- bei der Profilierung die Laufzeit nur minimal beeinflussen;
- erlauben, daß Zeitmarken an kritischen Stellen dynamisch zu- und abgeschaltet werden können;
- Aussagen über Art und Ausmaß der Parallelisierung ermöglichen;
- den Vergleich mehrerer Prozesse zulassen, um die Auswirkung von Optimierungsschritten feststellen zu können.
Die Compiler bereiten die meisten Probleme
Ähnliches gilt für den Debugger: Er sollte bei der Entwicklung hochoptimierter Supercomputer-Programme eine schrittweise Verfolgung der vektorisierten und parallelisierten Programme auf Quellcode-Ebene ermöglichen.
Vektorisierende und parallelisierende Compiler: Die im Bereich der Supercomputer wohl mit Abstand komplexeste Produktgruppe sind die Compiler. Ihre Bedeutung wird weiter zunehmen, da hardwarenahe Assembler-Programmierung oder der Einsatz architekturabhängiger Spezialsprachen allein schon aus wirtschaftlichen Gründen heute kaum mehr vertretbar ist. Die modernen Anwendungspakete sind zu komplex und ihre Lebensdauer ist zu lang (gemessen am typischen Generationszyklus von Rechenanlagen), als daß auf hardwareunabhängige Programmierung verzichtet werden könnte. Ein entscheidendes Kriterium bei der Bewertung eines Compilers ist also - neben der Fähigkeit, hochoptimierten Code zu erzeugen - die Kompatibilität zu echten oder De-facto-Standards.
Zur Beurteilung der Optimierungseigenschaften läßt sich der Quellcode grob in folgende charakteristische Bereiche unterteilen:
a) die Ebene der sequentiellen Abläufe: Programmkontrolle und Aufruf von untergeordneten Modulen; Verwendung skalarer Operanden sowie einer Vielzahl bedingter Sprünge.
b) die Ebene der Schleifen: Kernteile der Lösungsalgorithmen mit Verwendung indizierter Operanden (Arrays); komplizierte Indexoperationen und Sprünge innerhalb der Schleifen; bei mehrdimensionalen Problemen geschachtelte Schleifen (Schleifennester). c) die Ebene der Prozeduren: Abtrennung logisch zusammengehörender Teile (in der Regel durch Subroutinen realisiert); zeitlich zum Teil voneinander unabhängig.
d) die Ebene der Tasks: In der Regel unabhängige Programme oder Teile eines Einzelprogramms; Aufruf und Kontrolle durch das Betriebssystem.
Im Bereich a) ist der Spielraum für Compiler-Optimierungen weitgehend ausgeschöpft, sofern der "Blick" des Compilers ausschließlich auf die jeweilige Prozedur beschränkt bleibt. Signifikante Verbesserungen sind hier nur mehr mit "interprozeduralem Optimieren" möglich (siehe unten).
Auch im Bereich b) haben die vektorisierenden Compiler zumindest im Bereich der Vektorregistermaschinen einen sehr hohen Stand erreicht. Dies gilt nicht nur für Fortran, sondern bei einigen Herstellern auch für C und Ada.
Der durch die Vektorisierung erzielbare Leistungsgewinn liegt gegenüber skalarer Abarbeitung bei einem Faktor zwei bis über zehn, wobei in den rechenintensiven Programmkernen über 80 Prozent der theoretischen Spitzenleistung erreichbar sind. Die Vektorisierung bedeutet eine synchrone Parallelisierung des Programmablaufs (SIMD = single instruction, multiple data), das heißt, ein quasi-gleichzeitiges Abarbeiten von gleichartigen Operanden.
Schwieriger zu realisieren ist die andere Form der Parallelisierung, bei der mehrere Prozessoren unabhängig voneinander an Teilen des gleichen Programms arbeiten (asynchrone Parallelisierung). Rechenanlagen, die diese Möglichkeit bieten, werden als MIMD-Systeme (multiple instruction, multiple data) bezeichnet. Sie besitzen den Vorteil einer Vervielfachung der Leistung, ohne daß eine extrem teure Reduktion der Zykluszeit nötig wäre.
Eine Möglichkeit zur Parallelisierung besteht für den Compiler zunächst im Aufbrechen langer Vektoren in einzelne Teilvektoren, die dann unabhängig voneinander auf mehreren Prozessoren abgearbeitet werden können. Ein weiteres Parallelisierungs-Potential stellen Schleifennester dar, bei denen die Durchläufe der äußeren Schleife unabhängig von den Ergebnissen der inneren Schleifen und damit leicht parallelisierbar sind (während die inneren sich effektiv vektorisieren lassen). Interessant ist, daß in beiden Fällen automatisch parallelisiert werden kann, wobei die optimale Kombination von Vektorisierung und Parallelisierung natürlich hohe Ansprüche an den Compiler stellt.
Feinkörnige Parallelität: Noch komplizierter wird die Situation, wenn die einzelnen Schleifendurchläufe nicht mehr unabhängig voneinander durchgeführt werden können, weil innerhalb der Iterationen Synchronisationspunkte, zum Beispiel für den Austausch globaler Variablen, zu beachten sind. Auch diese Abläufe lassen sich prinzipiell automatisch parallelisieren, so daß der Sourcecode unverändert auf eine Workstation oder einen Minicomputer mit nur skalar arbeitender CPU übertragen werden kann.
Diese Optimierungstechniken sind zur Zeit nur auf Rechnern mit gemeinsamen Hauptspeicher (global memory) und entsprechender Kommunikationshardware zur schnellen Synchronisation der Prozessoren ohne Aufruf des Betriebssystems realisiert. Letzteres sichert eine effektive Nutzung auch feinkörniger Parallelität wie etwa bei kleineren Schleifenkonstruktionen.
Darüber hinaus besteht im Bereich c) die Möglichkeit einer parallelen Verarbeitung einzelner Prozeduren (Subroutinen, Funktionen), wobei wiederum die Konsistenz lokaler und globaler (shared) Variablen sichergestellt werden muß. Außer bei der Sprache Ada ist in diesem Fall der Compiler durch entsprechende Compiler-Direktiven im Quellcode zu unterstützen. Die Portabilität wird davon nicht beeinflußt, da diese Direktiven auf anderen Systemen als Kommentare aufgefaßt und ignoriert werden. Das Parallel Computing Forum (PCF) bemüht sich gegenwärtig um eine Standardisierung der Direktiven.
Die Behandlung noch größerer Einheiten im Bereich d), die unter Umständen nur noch über gemeinsame Dateien kommunizieren, führt in den Bereich des Multitasking, das normalerweise durch entsprechende Betriebssystem-Aufrufe realisiert wird. Ein wichtiges Bewertungskriterium ist hier der anfallende Overhead. Im Idealfall sollte der Systemdurchsatz proportional zur Prozessorzahl steigen.
Dank interprozeduraler Optimierung mehr Leistung
Interprozedurale Optimierung: Die neueste und aufwendigste Entwicklung im Bereich der Compiler-Technik stellt die interprozedurale Optimierung dar, die sowohl bei skalarer als auch bei vektorieller/paralleler Optimierung weitere Leistungssteigerungen bietet. Interprozedurale Optimierung bietet zusätzlich zu den klassischen Compiler-Leistungen:
- automatisches Einbinden von Prozeduren ("Inlining") und damit Reduktion des Call-Overheads sowie Vektorisierung und Parallelisierung über expandierte Prozeduren. Damit steht ein hochstrukturierter und modularer Programmierstil nicht mehr im Widerspruch zur Forderung nach Höchstleistung.
- "Constant Propagation" über Prozedurgrenzen. In vielen Fällen lassen sich Speicherzugriffe dadurch reduzieren, daß Konstanten anstelle der formalen Parameter direkt in den Code eingetragen werden. - "Procedure Cloning", das heißt die Vervielfachung von Prozeduren, die mit unterschiedlichen Konstanten als Argument aufgerufen werden. In Verbindung mit der Constant Propagation und dem Inlining können dadurch potentiell rekursive Strukturen vektorisiert werden;
- "Pointer Tracking" speziell innerhalb der Sprache C. Damit wird es zum Beispiel möglich, C-Programme, die in gutem "C-Stil" mit Pointern arbeiten (im Gegensatz zum "Fortran-Stil" mit indizierter Schreibweise), automatisch zu vektorisieren und parallelisieren; der interprozedurale Optimierer muß dazu über die Funktionsgrenzen "hinwegsehen", um Abhängigkeiten und potentielle Zugriffskonflikte (Rekursionen etc.) zu erkennen.
Schnittstellen für die Systemadministration
Im Leistungsbereich von Supercomputern gelten für die Systemschnittstelle die gleichen Anforderungen, wie sie typischerweise im Mainframe-Bereich gestellt werden. Die in den Standard-Unix-Implementierungen enthaltenen Möglichkeiten reichen hier bei weitem nicht aus. Zusätzlich gefordert sind, wie zum Teil schon erwähnt:
- "Fair-Share"-Scheduling;
- ein Batch-System auf NQS-Basis (IEEE 1003.10/15) einschließlich der Möglichkeit zum "Checkpoint/Restart";
- einstellbare Ressourcengrenzen gemäß einer Vielzahl von Kriterien auf Benutzer-, Gruppen- und Projektbasis;
- ein professionelles Abrechnungssystem;
- ein System zur Bandbearbeitung, einschließlich Folgebänder-Verwaltung und Vorreservierung;
- Anschluß von robotergesteuerten Tertiärspeichern (etwa Kassetten) und Sekundärspeichern (Disk-Pool);
- separates Operator-Interface mit eingeschränkten, einstellbaren Privilegien;
- Tools zur Kontrolle und Steuerung der Systemauslastung, insbesondere des Hauptspeichers, der CPUs und des I/O-Subsystems.
Es ist klar, daß bei derart komplexen Anforderungen die erste Frage nicht lautet: "Welches Unix?", sondern "Welche Funktionalität wird zur Verfügung gestellten?" Um hier klarere Verhältnisse herbeizuführen, arbeiten die Posix-Gremien an einer Standardisierung. Erste Ansätze zu Systemadministrations-Funktionen wurden mit dem IEEE-1003.7-Entwurf (ISO 9945-3) bereits vorgestellt.