Willy Weisz
Benchmarks sind Sammlungen von Aufgaben, die ein zu prüfendes Objekt lösen muß, wobei die Qualität der Lösung von den zu erhebenden Kriterien abhängt.
Im Bereich des EDV-Zentrums handelt es sich natürlich in erster Linie um Benchmarks zur Überprüfung von Rechnern und deren Bestandteile sowie Kommunikationseinrichtungen, es könnten aber auch Benchmarks für Software oder Dienstleistungen in Betracht kommen.
Von der Prüfungsseite her unterscheidet man Funktions- und Leistungsbenchmarks. Die ersteren überprüfen, ob geforderte oder angebotene Funktionen eines System tatsächlich vollständig und korrekt realisiert sind. Eventuell ermöglicht ein Funktionsbenchmark auch, die Leistungsfähigkeit der Funktionsbereitstellung zu messen (z.B. Geschwindigkeit, Nutzung von Hardware-Eigenschaften, Datensicherheit).
Der Leistungsbenchmark ist hingegen ausschließlich auf die quantitative Bestimmung von Leistungsmaßzahlen ausgelegt. Dabei wird die Verfügbarkeit und korrekte Arbeitsweise der benötigten Funktionen vorausgesetzt. Erhobene Leistungszahlen können u. a. sein: Dauer (Prozessor- und Gesamtlaufzeit), Gesamtmenge an transportierten oder gespeicherten Daten, Anzahl von Operationen oder verarbeiteten Daten pro Zeiteinheit.
Woher kommen die Tests zur Bestimmung der Leistung? Hier unterscheidet man 2 Klassen von Benchmarks: Bench-marks, die aus Benutzer-Jobs zusammengestellt sind, und synthetische Benchmarks.
In der folgenden Diskussion wird implizit von Bench-marks zur Leistungsmessung von Rechensystemen ausgegangen. Analogieschlüsse auf die Bewertung anderer Komponenten sollten jedoch leicht durchführbar sein.
Benchmarks dieser Art haben den Vorteil, daß sie einen Satz real vorgekommener Aufgabenlösungen für die Leistungsmessung heranziehen. Werden diese Benchmarks eingesetzt, wird im Allgemeinen die Verarbeitungsdauer der Programme als Maßzahl eruiert. Ein solches Vorgehen ist dann bestens geeignet die optimale Hard- und Software-Konfiguration zu ermitteln, wenn auch in Zukunft gleichartige Aufgabenstellungen (mit den gleichen Programmen) zu bearbeiten sind.
In kommerziellen Umgebungen mit sich nur wenig ändernden Programmen und mit einem leicht überschaubaren Satz an Programmen, „auf die es ankommt“, ist solch eine Vorgangsweise in den meisten Fällen adäquat. Die Berücksichtigung der Auswirkungen von Neuentwicklungen ist dabei jedoch nur dann möglich, wenn ausreichend Detailwissen über das Zusammenwirken der einzelnen Programmteile mit der Hard- und Software-Umgebung vorhanden ist.
In sich schnell erneuernden Programmierumgebungen ist diese Form des Benchmarks nicht wirklich aussagekräftig. Vor nicht allzu langer Zeit galt der Benchmark aus Benutzer-Jobs als der wahre Maßstab, weil er ja das reale Benutzerverhalten widerspiegelt. Das Problem dabei ist, daß es sich dabei meist um sehr komplexe Programme handelt, deren Verhalten bei der Leistungsmessung nicht wirklich interpretiert werden kann. Die erhobenen Daten sind globale Laufzeitdaten (selbst bei benutzerdefinierten Zeitmessungen im Programm) und lassen daher nicht wirklich Schlüsse auf die Leistungsfähigkeit für andere Programme oder Programm versionen zu. In sich häufig verändernden Benutzungsumgebungen stellen sie immer nur einen Blick zurück dar. Daher gehen immer mehr Fachleute dazu über, synthetische Benchmarks zu verwenden, deren Inhalte jedoch teilweise aus Benutzerprogrammen stammen.
Ein weiterer Nachteil ergibt sich, wenn eine Auswahl von Hard- und Software „ohne Vorurteile“ getroffen werden soll. „Vorurteile“ entstehen dadurch, daß rechenintensive Programme für eine Rechnerarchitektur oder gar einen Rechnertyp optimiert werden. Werden sie zur Auswahl eines Rechensystems herangezogen, so kann diese Vorbestimmung des Code zur Ermittlung eines lokalen, aber nicht des absoluten Optimums unter den getesteten Systemen führen. Diese Vorab-Bevorzugung durch einen Benutzer kann vom auswählenden EDV-Zentrum meist nicht erkannt werden.
Synthetische Benchmarks bestehen aus Programmteilen, deren Zusammenspiel mit der Hard- und Software-Umgebung verstanden wird. Da dies bei beliebigen Programmen aus der Benutzerschaft nicht möglich ist, werden Standard- Benchmarks zusammengestellt und für die Leistungsbestimmung verschiedener Systeme herangezogen. Ist die wahrscheinliche Nutzungsstruktur des auszuwählenden Systems bekannt, kann man durch Gewichtung der Leistungsmaßzahlen der eingesetzten Programmteile das beste Anbot auswählen.
Parametrisierte Benchmarks, bei denen gezielt eine oder mehrere Größen (wie z.B. die Dimension von Datenfeldern) variiert werden, der Algorithmus aber gleich bleibt, erlauben es, die Reaktion des Systems auf sich ändernde Umstände zu analysieren. Insbesondere liefern sie eine Bandbreite für die erzielbare Leistung.
Selbstverständlich werden gute synthetische Benchmarks nicht auf dem Reißbrett entwickelt, sondern es werden Teile von reell eingesetzten Programmen verwendet; oft handelt es sich dabei um Teile, in denen die meiste Rechenzeit verbraucht wird. Diese für die Leistungsmessung besonders relevanten Befehlsfolgen werden als „Kernels“ bezeichnet.
Einige dieser Programmsätze werden als genormte Bench-marks veröffentlicht oder sind gegen Kostenersatz erwerbbar: SPEC (Standard Performance Evaluation Corporation), Linpack, ParkBench, Livermore Loops usw. Trotz der im Allgemeinen guten Dokumentation der dabei zum Einsatz kommenden Programme werden die Ergebnisse oft durch Vereinfachung irreführend interpretiert: Meist wird entgegen den Anweisungen immer nur ein rechnerisch ermittelter Mittelwert zur Bewertung herangezogen, statt daß man sich mit den Leistungsergebnissen jedes einzelnen Teils auseinandersetzt und dessen Relevanz für das zu bewertende System untersucht und die Werte entsprechend gewichtet.
Aber auch genormte Leistungsbenchmarks haben nur eine zeitlich begrenzte Einsetzbarkeit: Waren früher Cache-Speicher von einigen Kbyte üblich, so werden heute auch günstigste Workstation oft mit einigen Mbyte an Cache ausgeliefert; Programme, mit denen früher die Leistungsfähigkeit des Zugriffs zum Hauptspeicher bestimmt wurde, messen heute oft nur mehr den Datenaustausch zwischen Cache und Prozessor. Deshalb wird z.B. bei SPEC die Aussagekraft ihrer Benchmark-Suite auf 3 Jahre begrenzt geschätzt; für die nächste Generation (SPEC98) wird bereits aufgerufen, Meßprogramme für zukünftige Systeme vorzuschlagen.
Die Hardware-Leistung allein sicher nicht mehr. Außer bei einem PC unter DOS kann nicht einmal mehr mit Assembler-Programmen die reine Hardware-Leistung gemessen werden. Alle modernen Betriebssysteme beeinflussen auf vielfältige Weise den Ablauf eines einzelnen Programms oder Prozesses.
Bei Programmen, die in höheren Programmiersprachen verfaßt sind, ist die Optimierung durch den Compiler und die Unterstützung durch optimierte Laufzeitbibliotheken ein manchmal sogar die Hardware übersteigender Faktor bei der Leistungssteigerung.
Was also wirklich gemessen wird, ist das Zusammenspiel von Hardware, Sprachprozessoren und Laufzeitumgebung. Das ist es aber auch, womit der Benutzer konfrontiert wird.
Also ganz einfach - oder? Es gibt Funktionen, die man mit den traditionellen Benchmarks, auch mit den meisten Benutzer-Jobs, gar nicht mehr messen kann. Dazu zählt zum Beispiel das Schreiben und spätere Einlesen selbst großer Dateien. Viele Programme, die bis vor kurzem noch zum Messen des Transfers von Daten von und zu Plattenspeichern dienten, messen heute dank großer Hauptspeicher und UNIX nur mehr den Transfer von und zum Hauptspeicher, da der gesamte Datenbestand während des Programmlaufs dort zwischengespeichert zur Verfügung steht. Wie leistungsfähig die Plattenperipherie und die Pfade dorthin sind, kann nur durch aufwendigeres Testen festgestellt werden. Noch schwieriger ist die Messung der Leistungsfähigkeit von Mehrprozessorsystemen mit gemeinsamem Hauptspeicher. In der typischen Testsituation ist es sehr sehr schwierig, einen Benchmark-Job in eine Nutzungsumgebung einzubetten, wie sie im realen Betrieb besteht. Der effektive Zugriff zum Hauptspeicher durch alle anderen Prozesse (sehr intensiv bei Programmen, die intern oft umspeichern, wie z.B. die NFS-Dämonen) bestimmt die Leistung, die ein Testprogramm aus dem Prozessor herausholen kann.
Antwortzeit: Zeitdifferenz zwischen Beginn und Ende des Programms oder der gesamten Suite.
Prozessor-Zeit (cpu-time): die Zeitspanne, die das Programm den Prozessor für sich einsetzt.
MIPS (million instructions per second): wenig aussagekräftige Größe bei Vektor- und Superskalarprozessoren, daher auch als Abkürzung für „meaningless indicator of processor speed“ gehandelt.
Flop/s, Mflop/s, Gflop/s (oder schlampiger: Flops, Mflops, Gflops): Anzahl der Gleitkommaoperationen pro Sekunde.
Genauere Definitionsangaben finden sich im Artikel „Leistung von Computersystemen“ in dieser Ausgabe.
Als Ergänzung zu den Ausführungen dort noch ein Hinweis zur Anzahl der Gleitkommaoperationen: Es gibt verschiedene Methoden zur Definition dieser Anzahl:
Die zuletzt beschriebene Methode wird heute meistens für die Ermittlung der Leistungszahl (M)(G)flops herangezogen und wird auch in den Artikeln „Leistung von Computersystemen“ und „Effizienzsteigerung durch Blockung“ verwendet.
SPEC: http://www.specbench.org/
Frei erhältliche Benchmark-Programme und Ergebnisprotokolle: http://www.netlib.org/benchmark/
The Performance Database Server: http://www.netlib.org/performance/html/
PDStop.html
ParkBench: http://www.netlib.org/parkbench/