Exklusiv für CW, Von Dr. Peter Molzberger und Dr. Franz Peschanel
MÜNCHEN - Technischwissenschaftliche Programme werden in der Regel in Fortran und eventuell PL/1 geschrieben, - von guten und schlechten Programmierern. Nach einer Untersuchung der System Development Corp. verhielten sich die Laufzeiten von Programmen - jeweils erstellt vom besten und vom schlechten Programmierer einer Gruppe - wie 1 : 13.
Typisch für die Struktur technisch-wissenschaftlicher Programme ist ihr ausgeprägter Aufbau aus ineinanderliegenden Schleifen, wie sie beispielsweise zur Matrixbearbeitung und zu Iterationen verwendet werden. Dabei wird die innerste Schleife außerordentlich viel häufiger durchlaufen als die äußeren Programmteile. Häufig besteht die innerste Schleife nur aus wenigen Programmweisungen meist mathematischer Natur.
So ist der Fall nicht selten, daß 99 Prozent der CPU-Zeit in nur einem Prozent der Programmstatements verbraucht werden.
Auf die inneren Programmschleifen achten
Gelingt es - auch in weniger extremen Fällen - diese inneren Programmteile auch nur um einen mäßigen Faktor zu beschleunigen, so schlägt dieser fast voll auf die Gesamtlaufzeit durch. Andererseits lohnt es nicht, an einer besseren Codierung der übrigen Programmteile einen Gedanken zu verschwenden.
Der Rat, den erfahrensten verfügbaren Programmierer zur Überprüfung derartiger Brennpunkte einzusetzen, ist keineswegs mehr trivial. Starke Effizienzsteigerungen sind zu erzielen, wenn man bereit ist, an den beschriebenen Brennpunkten Assembler-Codierung einzusetzen - womit eine gewisse Maschinenabhängigkeit in Kauf genommen wird. Zwar erzeugen moderne Fortran- und PL/1-Compiler einen sehr laufzeiteffizienten Code, es bleiben jedoch eine Reihe von Möglichkeiten ungenutzt, die die Sprache nicht unterstützt (oder die - in PL/1 - umständlich zu handhaben sind).
Vier Rezepte
Die Standard-Genauigkeit einer Sprache ist nur für die wenigsten Probleme wirklich notwendig. Iterationen könnten meist früher abgebrochen werden.
Sehr viel Verwaltungszeit geht verloren beim Aufruf von Standardfunktionen in inneren Schleifen. Hier kann man durch Assembler-Programmierung hohe Einsparungen erzielen. Es ist jedoch zu beachten, daß auch ein Assembler-Unterprogramm sehr aufwendig nach den Standardkonventionen eingebunden wird. Man sollte daher die innersten Schleifen möglichst mit in das Unterprogramm einbeziehen.
Gravierender noch sind Fragen der Datenorganisation. Sämtliche Zahlenwerte werden zum Beispiel in Fortran mit Standardlängen gespeichert - im Extremfall ein binärer Wert in einem 48-Bit-Wort. Bei Assembler-Codierung kann man beispielsweise einen Wert, der - wie in den Sozialwissenschaften üblich - in einer 8stufigen Taxonomie vorliegt, wirklich in 4 Bits unterbringen. Bestehen zu speichernde Matrizen zum großen Teil aus Nullen, so lassen sich diese weiter komprimieren.
Mit Hilfe dieser beiden Verfahren gelang es in einem Fall, eine Matrix, die in Fortran über eine Million Worte benötigt hätte, auf zirka 100 K-Bytes zusammenzudrücken.
Überraschen mag dabei die Tatsache, daß die Verarbeitung einer komprimierten Matrix schneller vonstatten gehen kann als im entkomprimierten Zustand. Entscheidender noch macht sich jedoch der Speicherplatz-Effekt bemerkbar.
Die eben erwähnte Matrix wird man in der Regel in einem Fortran-Programm nicht im Kernspeicher halten können. Sie muß - entweder vom Programmierer oder vom virtuellen Betriebssystem - auf eine Platte oder Trommel ausgelagert werden. Speichert man sie dagegen komprimiert, entstehen derartige Probleme nicht.
So kann aus einem extrem E/A-intensiven Programm ein reines CPU-Programm werden, mit stark reduzierter Gesamt-Laufzeit.
Spezialisten für das Team
Da es in vielen Fällen mit Hilfe gezielter Maßnahmen möglich ist. Laufzeiten von Stunden auf Minuten herabzusetzen, lohnt sich bei häufigen und lang laufenden Programmen eine kritische Überprüfung. Mehr noch sollte man derartige Gesichtspunkte bei der Neukonzeption von Programmen berücksichtigen.
Die Schwierigkeit besteht darin, daß sich auch hervorragende wissenschaftliche Programmierer in den systemlichen Fragen nicht ausreichend auskennen und zum Beispiel bereits vor dem Anschluß eines Assembler-Unterprogramms zurückschrecken. Dieser Personenkreis ist auch von Ausbildung, Aufgabe und Erfahrungshorizont her in der Regel nicht in der Lage, eine Anzahl von softwaretechnischen Lösungswegen für ein Problem zu sehen und die notwendigen problembezogenen Laufzeitberechnungen auszuführen.
Man wird den Nicht-EDV-Fachspezialisten auch nicht so hoch ausbilden können daß er die Probleme der Laufzeitoptimierung übersieht. Aber in seinem Team sollte ein Informatiker present sein, der Erfahrung in der Systemprogrammierung und in der Organisation großer Programmpakete hat.
Die Autoren sind Leitende Mitarbeiter der GfS, Gesellschaft für Systementwicklung, München.