"Bei uns ist ja alles ganz anders", sagte der Chef der EDV und entwickelte einen neuen Benchmark. Die Zahl der Individualisten nimmt nicht ab, Standardisierungsbestrebungen blieben bisher ohne Erfolg. Der Aufwand, der für Benchmarks getrieben wird, steht nicht im Verhältnis zu seiner Aussagekraft.

Ist es möglich, ein Verfahren zu normieren, das mit vertretbarem Aufwand (Zeit, Kosten) eine Aussage über das Zeitverhalten von Rechensystemen liefert?

An Normungsbestrebungen hat es sicher nicht gemangelt. Zur Zeit untersucht die Deutsche Elektronische Kommission (DKE) im DIN und VDE die Möglichkeit zur Normung eines Testverfahrens auf nationaler Ebene. Der eingesetzte Unterausschuß beschäftigt sich mit dem "Konstanzer Leistungstest". Ist es der letzte Versuch?

In vielen Artikeln und Büchern wird von Mixen, Kernels, Benchmarks, Whetstones oder mittleren Operationszeiten berichtet. Schon für die Begriffe wäre eine Normung vonnöten, geschweige denn bei der Verwendung von Testverfahren.

Akzeptanz nicht gegeben

Ein Artikel wie dieser kann Normierungsarbeit nicht leisten, es müßte ein Gremium ("Notgemeinschaft von Benchmark-Geschädigten") geben, in dem Anbieter von Rechensystemen und Anwender bemüht sind, einen Weg zu finden, auf dem Kosten abgebaut und Transparenz erhöht werden.

Aus 15jähriger Erfahrung mit etwa 200 Benchmark-Programmen und "Sogenannten" sollen hier drei Beispiele die Situation schildern.

Testfall 1: Ein RZ-Leiter nimmt 56 Fortran-Programme von der Rutsche und deklariert dieses Paket zu seinem Job-Profil. Aus einem Duplikat dieses Paketes werden wahllos in allen Programmen Karten gezogen und weggeworfen. Diese nun fehlerhaften Programme repräsentieren seine Programm-Entwicklungssituation. Ein Programm wurde noch eliminiert, weil es nur noch aus (fehlerfreiem) Kommentar bestand. Fertig war der Benchmark: 111 Programme mit 12 000 Lochkarten.

Testfall 2: Eine Behörde beauftragt ein SW-Haus mit der Durchführung eines Benchmark-Testes. Nach Konzept- und Definitionsphase programmieren schließlich 6 Mitarbeiter für 6 verschiedene Rechensysteme; jeder für sich in Assembler.

Testfall 3: Ein Forschungsinstitut erwirbt ein Fortran-Programm-Paket von einer amerikanischen Universität als Grundlage für ein neues Projekt. Auf Magnetbändern findet sich dieses Paket als Anlage zur Angebots-Aufforderung für eine Rechenanlage wieder. Dieser Benchmark soll den Nachweis erbringen, daß das Projekt mit dem auszuwählenden Rechner in der vorgegebenen Zeit abgewickelt werden kann.

Aus diesen Kurzdarstellungen von drei Testfällen ist ohne nähere Ausführungen ersichtlich, daß die Implementierung solcher Benchmarks und die Durchführung von Testserien sowohl die Anwender als auch die Anbieter von Rechensystemen monatelang beschäftigt. Die Auswertung der Testserien (oft mehrere hundert Druckseiten) ist nicht mehr durchführbar, es sei denn, man entwickelt jeweils ein Benchmark-Auswerte-Programm.

Bei einigen Benchmarks liegt der Verdacht nahe, daß der Test nur eine getarnte Umstellung vorhandener Programme für die neue Rechenanlage ist. Es wundert nicht, daß zunehmend mehr Anbieter solche aufwendigen und wenig transparenten Benchmark-Tests ablehnen.

Der "Konstanzer Leistungstest" lebt seit 1966. Für die Qualitätskontrolle eines Großrechners wurden kapitelweise aus Benutzerhandbüchern Funktionen definiert und in Testprogramme umgesetzt. Diese Methode ist bekannt und wird neben anderen Kontrollverfahren (HW-/SW-Monitore, Meßgeräte) auch von anderen EDV-Benutzern angewandt.

Mit solchen Funktionstests läßt sich herausfinden, ob die angebotene Leistung eines Rechensystems so funktioniert, wie sie beschrieben ist. Gleichzeitig kann durch Einbau von Zeitabfragen ermittelt werden, wie lange die Abarbeitung einer Funktion dauert (Verweilzeit t(vw)) und wie lange dafür der Zentralprozessor belegt ist (Zentralprozessorzeit t(zp)).

Die Leistungsmessung mit diesem synthetischen Benchmark wird verwendet für

- die Qualitätskontrolle,

- das Tuning des Rechensystems,

- das Tuning von Anwendungssystemen,

- die Auswahl von fremden Rechensystemen

Seine Bewährungsprobe, bestand der "Konstanzer Leistungstest" im Jahre 1972, als für die Lohn- und Gehaltsabrechnung von 16 000 Mitarbeitern 3 Batch-Rechner, durch einen Großrechner abgelöst werden sollten.

Es stand zur Diskussion, ob

A die Lohn- und Gehaltsprogramme tatsächlich umgestellt werden sollten, um sicher zu gehen, daß der neue Rechner die Aufgaben übernehmen konnte oder

B der Nachweis mit einem synthetischen Benchmark für einen Vertragsabschluß von mehreren Millionen Mark akzeptiert würde.

Der "Konstanzer Leistungstest" konnte 1972 gegenüber Lösung A nicht überzeugen, bekam aber die Chance, parallel zu A die Eignungskriterien zu ermitteln.

Die Umstellungsprogrammierer (Lösung A) mußten massenweise

Lochkarten wälzen und umlochen (60 Prozent Assembler und 40 Prozent Cobol), die Systemanalytiker (Lösung B) ließen sich fünf Wochen lang das Programmpaket erklären und kristallisierten die wesentlichen Funktionen und deren Wiederholungsfaktoren heraus.

Aufwand für Lösung A: 15 Programmierer, 6 Monate, 8000 Stunden, Rechenzeit.

Aufwand für Lösung B: 3 Systemanalytiker, 6 Wochen, 20 Stunden Rechenzeit.

Seit dieser, Zeit ist der "Konstanzer Leistungstest", ausgebaut und vereinheitlicht, Bestandteil der Qualitätskontrolle, des Systemtunings und der Rechnervergleiche. 1980/81 lief der Test auf folgenden Rechnern:

- AEG 80-20/5 und /6,

- PDP 11/34 und 11/50,

- HP 1000,

- IBM Serie /1,

- Classic 7870,

- PE 8/32,

- VAX 11/780,

- Siemens R30.

Das Zeitverhalten eines Rechensystems bei der Ausführung einer definierbaren Funktion/Funkionsfolge (Anwenderprofil) ist ein meßbares Kriterium, um die Eignung eines Rechensystems für die vorgebbare Aufgabe beurteilen zu können. In der Regel wird das Zeitverhalten in Zusammenhang mit anderen Eignungskriterien, wie Ausbaufähigkeit, Software-Support, Bedienungskomfort oder Diagnostik, zu sehen sein. Mit dem "Konstanzer Leistungstest" soll eine Aussage über das Zeitverhalten möglich sein, die Bewertung ist nicht Bestandteil dieses Verfahrens.

Der Test ist ein synthetischer Benchmark, der folgende Voraussetzungen erfüllt:

- einheitlicher Testrahmen,

- parametrierbare Initialisierung und Testdurchführung,

- transparenter Programmaufbau (übersichtliche Struktur, linear programmiert, einfache Erweiterbarkeit),

- portable Form (Sprache zum Beispiel Standard-Fortran nach ISO/R 1539 [DIN 66027] mit Prozeß-Fortran nach VDI/VDE-Vorschlag, Umsetzung in andere, genormte Sprachen leicht möglich),

- reproduzierbare Testabläufe,

- einheitliche Testquittung.

Durch diese Voraussetzungen ist der Umstellungsaufwand zwischen Rechensystemen verschiedener Hersteller sehr gering, der Umfang des Outputs auf einzelne Zeilen begrenzt und die Rechenzeitanforderung je nach Problem einstellbar. Diese Eigenschaften ermöglichen eine Aussage mit vertretbarem Aufwand und dadurch eine hohe Akzeptanz bei Anbietern und Anwendern.

Voraussetzung für die Anwendung eines synthetischen Testverfahrens ist die Fähigkeit, Aufgaben, Probleme und Forderungen zu analysieren und Funktionen herauszukristallisieren. Kritiker des, "Konstanzer Leistungstests" akzeptieren zwar sofort seine einfache Methode, bezweifeln aber, ob die Benutzer (beispielsweise ein Sachbearbeiter) fähig sind, ihr Anwendungsprofil zu analysieren.

Eine solche Qualifikation ist allerdings nicht nur für den Test erforderlich, sondern auch für Design und Entwurf von Programmen. Weitere Ausführungen zu dem zur Zeit viel beschriebenen Thema "Systemanalyse als Schlüssel der Zukunft" sollen hier nicht erfolgen.

Aus eigener Erfahrung ist die Kritik an der Qualifikation der Sachbearbeiter für die Anwendung des "Konstanzer Leistungstests" unberechtigt (wenn Kritik, dann sollte man sie viel höher ansetzen). Bestätigt wird diese positive Meinung durch die Arbeit des DKE-Ausschusses, dessen Mitglieder bei der Erarbeitung von Funktionsbeschreibungen ausgezeichnete Erfolge zu verzeichnen haben.

Zur Durchführung der Tests wird ein einheitliches Testrahmenprogramm verwendet. Ein Testrahmen besteht aus Vorlauf, Testfunktion und Nachlauf. Im Vorlauf werden die Parameter für Initialisierung und Steuerung eingelesen und quittiert, im Nachlauf Ergebnisse aufbereitet und ausgegeben.

Beginnend mit der Abfrage der Anfangszeit (t(A)) am Ende des Vorlaufes und endend mit der Abfrage der Endzeit (t(E)) zu Beginn des Nachlaufes wird der Test der programmierten Testfunktion durchgeführt. Die Differenz zwischen Anfangs- und Endzeit ist die Verweilzeit (t(vw) = t(E) - t(A)), die für die Abarbeitung der Testfunktion benötigt wurde.

Die Testquittung wird für alle Tests einheitlich im Testrahmen erzeugt und ausgegeben. Die Quittung wird in das Testprotokoll übernommen.

VW- Zeit und ZP-Zeit

Die Verweilzeit (t(vw)) ist das erste meßbare Kriterium dieser Testmethode. Für eine Aussage über die Dauer (t(vw)) einer Funktion (Beispiel: Schreiben von 1000 Sätzen der Länge 256 Byte im Random-Zugriff auf eine Wechselplatte) muß dieses Programm als einziges Anwenderprogramm im Rechner ablaufen, um Einflüsse durch andere Programme auszuschließen.

Die Belegung beziehungsweise Blockierung des Zentralprozessors (ZP) für die Abarbeitung der Funktion ist das zweite meßbare Kriterium dieser Testmethode. Da die Ermittlung der bei einem Test benötigten ZP-Zeit (t(zp)) nicht bei jedem Rechner durch Betriebssystemfunktionen, die die ZP-Zeit verwalten, möglich ist, wird zur Erfassung der ZP-Zeit folgende transparente Methode verwendet:

- ein Grundprogramm wird als Hintergrundprogramm priorisiert und startbereit geladen;

- als Funktion ist in diesem H-Programm eine reinarithmetische Statementfolge eingebettet, die den Zentralprozessor voll belegt;

- die VW-Zeit dieses H-Programmes ist gleichzusetzen mit der ZP-Zeit;

- über Parameter wird die Laufzeit des H-Programmes eingestellt;

- das eigentliche Testprogramm läuft im Vordergrund, gibt es den Zentralprozessor frei, nimmt das H-Programm die freie ZP-Zeit auf;

- die eingestellte Laufzeit des H-Programmes verlängert sich um die Zeit, die das Testprogramm den Zentralprozessor benötigt hat.

In der so ermittelten Zeit ist auch die Zeit enthalten, die das Betriebssystem zum Umschalten zwischen beiden Programmen braucht. Aus Anwendersicht - und dafür ist der "Konstanzer Leistungstest" entworfen, ist diese Systemzeit Bestandteil der ZP-Belegung für die Ausführung einer Funktion, einer Funktionsfolge oder eines Anwenderprofiles. Wer Einzelheiten wissen will, an welchen Ecken des Rechensystems die Zeit verbleibt, wird spezielle Meßprogramme verwenden.

Für den "Konstanzer Leistungstest" gilt, daß der Tester die Einflüsse, die auf die VW-/ZP-Zeiten wirken, möglichst durch Testschritte ausfiltert, - und wenn ihm das nicht möglich ist, sie gewissenhaft

protokolliert.

Damit eine möglichst gezielte Aussage erreicht werden kann, ist es wichtig, schrittweise vom Test einer einzelnen Funktion über den Test einer Funktionsfolge zur Zusammenstellung eines Anwenderprofiltestes vorzugehen.

Sind die einzelnen Funktionen getestet, können in ein Testprogramm mehrere Funktionen (zum Beispiel Lesen eines Satzes, Byte-Verarbeitung, Schreiben eines Satzes) zur Konstruktion eines Anwendungsfalles hintereinandergelegt werden. Anwendungsprofile lassen sich auf verschiedene Weise erzeugen:

a) Einbringen mehrerer Funktionen/ Funktionsfolgen zur sequentiellen Abarbeitung in ein Testprogramm

b) Aufteilen mehrerer Funktionen/ Funktionsfolgen zur parallelen Abarbeitung in mehrere Testprogramme

c) Mischung von a) und b).

Es darf nie mehr als eine Veränderung vorgenommen werden, um eine detaillierte Aussage zu bekommen.

Gutes Protokoll, keine Bewertung

Die Testergebnisse werden durch verschiedenartige Faktoren beeinflußt:

- Konfiguration des Rechensystems,

- Optimierungsmaßnahmen für den Anwendungsfall,

- gewählte Programmiersprache,

- Betriebssystemfunktionen, die mit gemessen werden,

- Struktur der Anwendungsprofile,

- menschliche Einflüsse,

- und andere.

Die Systemkonfiguration sollte so gewählt werden, daß sie einmal das Anwendungsprofil bestmöglichst unterstützt und andererseits auch die Vergleichbarkeit der Rechensysteme erlaubt.

Die Bewertung aller Faktoren ist nicht Bestandteil der Ergebnisse. Je nach Zweck des Testes, zum Beispiel für die Rechnerauswahl, das Tuning des eigenen Anwendungs-Systems, hat der Wert einer Maßzahl einen anderen Hintergrund. Die Bewertung aller Faktoren und Meßergebnisse muß einem anderen Verfahren vorbehalten bleiben.

Damit für ein späteres Bewertungsverfahren vom Test her nicht nur eine einzelne Zahl im Raume steht (Rechner A braucht 10 Sekunden, Rechner B nur 3 Sekunden, also ist B 3,3 mal besser als A), ist ein ausführliches Testprotokoll unabdingbar. Es ist eine verbale Beschreibung der Testvorbereitung, der Testdurchführung und der Testergebnisse. Es enthält:

- die Beschreibung und den Durchführungsplan des Gesamttests,

- die Beschreibung der einzelnen Funktionen,

- die Beschreibung der Testumgebung: Die ausgewählte Konfiguration muß in ihren für den Test relevanten Teilen (Gleitpunktprozessor, E/A-Prozessor, Speichergröße, E/A-Geräte, Systemversion etc.) präzise beschrieben werden,

- die Beschreibung (mit Uhrzeiten) der Anlagen-spezifischen Vorbereitungsmaßnahmen und der Testdurchführung selbst,

- die Testergebnisse einschließlich aller vom Rechner ausgegebenen Testquittungen.

Außerdem sollte im Testprotokoll Platz sein für eine Stellungnahme des Anbieters zur Diskussion der Ergebnisse.

Der "Konstanzer Leistungstest" ist nicht das Nonplusultra der Benchmark-Technik. Im Gegenteil, er ist eher ein bescheidener Test, allerdings mit vielen Vorteilen, die die Möglichkeit zur Normung vorzeichnen. Von Programmentwicklung bis zur Qualitätssicherung ist der Ruf nach (Semi)Formalien zur Steigerung von Produktivität und Wirtschaftlichkeit laut. Normung ist eine Voraussetzung zur Zeit- und Kostenersparnis.

Der Ausschuß der Deutschen Elektronischen Kommission hat sich zum Ziel gesetzt, in Abstimmung zwischen Anbietern und Anwendern ein Testverfahren zu normen, um dem Benchmark-Wirrwarr Einhalt zu gebieten. Es gilt:

- die Methode zu beschreiben,

- Begriffe festzulegen (zum Beispiel CPU-Zeit oder ZP-Zeit),

- Funktionen von Rechensystemen herauszukristallisieren unter Wahrung der Sprachunabhängigkeit (verbale Beschreibung bis Pseudo-Code),

- Beispiele (in Fortran, Pearl, Pascal und anderen) zum leichteren Einstieg anzufahren.

Und wenn alles genormt ist, muß das Verfahren auf unterschiedlichsten Rechensystemen verschiedener Anbieter ausprobiert werden (trusted tests).

*Siegfried Schall ist Beauftragter für Rechnervergleiche und für den Einsatz von Software-Entwicklungsmethoden bei AEG-Telefunken zuständig.