SPEC-Benchmarks
Unter dem Namen "System Performance Evaluation Cooperative" (SPEC) schlossen sich 1988 vier Herstellerfirmen, vor allem Hersteller von RISC-Mikroprozessoren, zusammen um durch eine Zusammenstellung von geeigneten Benchmarks eine einheitliche Basis für die Leistungsbewertung von Computern und speziell von Mikroprozessoren des oberen Leistungsbereichs zu schaffen. Inzwischen sind weitere bedeutende Firmen beigetreten, heute beteiligen sich an SPEC AT&T, Bull, CdC, Compaq, Data General, DEC, Du Pont, Fujitsu, Hewlett-Packard, IBM, Intergraph, MIPS, Motorola, NCR, Siemens Nixdorf, Silicon Graphics, Solbourne, Stardent, SUN und Unisys.
Ausgangspunkt für SPEC war ein weit verbreitetes Gefühl der Unzufriedenheit mit Leistungsangaben insbesondere in der Mikroprozessor-Welt: Jeder Hersteller gibt MIPS- und MFLOPS-Werte für seine Produkte an, aber es gab und gibt keine verbindliche Definition, wie diese Werte zu gewinnen sind [1]. Die wörtliche Definition von MIPS als "Million Instructions Per Second" hat für Vergleiche zwischen unterschiedlichen Prozessorlinien und vor allem zwischen RISC- und CISC-Prozessoren (Reduced bzw. Complex Instruction Set Computer) jegliche Relevanz als Maßstab für den Kunden verloren. Der RISC-Ansatz bedeutet ja gerade, ein Programm aus der höheren Sprache in mehr, aber einfachere und daher wesentlich schnellere Befehle zu übersetzen. Auch der Ausweg, die wörtliche Bedeutung von MIPS" zu ignorieren und unter der MIPS-Zahl das Verhältnis der Leistung im Vergleich zu VAX11/780 zu verstehen (ein in der Handelspresse oft übliches Verfahren), hat seine Probleme, denn die Auswahl der zu messenden Programme, der Programmiersprache und der Compiler für die VAX hat großen Einfluß auf das Ergebnis.
Einen Ausweg bieten Benchmark-Programme, die für einen bestimmten Bereich der Programmierung (z.B. numerische Programmierung, Systemprogrammierung) repräsentativ sind. Sie wurden entweder als Kernels" aus häufig durchlaufenen Programmteilen von realen Anwendungsprogrammen herausdestilliert oder als synthetische Benchmarkprogramme eigens zur Leistungsmessung konstruiert. Heute werden vor allem Whetstone und Linpack (für Numerik-Programmierung) sowie Dhrystone (für System-Programmierung) eingesetzt. Wenn auch synthetische Benchmark-Programme den Vorteil haben, daß sich ihre Eigenschaften wie die Prozentzahlen für die verschiedenen Statement-Arten und Datentypen beobachteten Programmprofilen gut anpassen lassen, haben sie doch zwei wesentliche Nachteile:
- Bei der Kürze der Programme fällt es Compiler-Autoren verhältnismäßig leicht, die Codeerzeugung und die Auswahl der Optimierungen auf diese Benchmarks abzustimmen; einzelne Elemente des Benchmarkprogramms können dann bei gezielt ausgewählten Codeoptimierungen die Laufzeit überproportional beeinflussen.
- Da die Programme verhältnismäßig kurz sind (Whetstone: meist unter 256 Byte pro Modul; Linpack/saxpy: 240 Byte; Dhrystone: ca. 1000 Byte) (Codelänge-Angaben für die Meßschleifen oder (bei Linpack) für das die Ausführungszeit dominierende Unterprogramm saxpy", compiliert für VAX 11 mit Compilern von Berkeley UNIX), werden sie fast vollständig aus dem Cache heraus ausgeführt, das Speichersystem wird - außer bei Linpack für den Datenbereich - nicht realistisch getestet.
Aus diesem Grund hat sich SPEC zur Aufgabe gemacht, große Anwendungsprogramme zu sammeln und in normierter Form als Benchmark-Suite zur Verfügung zu stellen. Dies ist ein nichttriviales Unternehmen, da viele Programme, die vorher neben den kurzen Benchmarks für Leistungsmessungen verwendet wurden (z.B. nroff, yacc), eine UNIX-Lizenz erfordern und daher nicht frei weitergegeben werden können.
Die erste SPEC-Suite wurde im Herbst 1989 freigegeben, sie umfaßt 10 Programme mit zusammen etwa 150000 Zeilen Quellcode. Vier der Programme sind in C geschrieben, sechs in FORTRAN. Auch die Charakteristiken der Programme sind unterschiedlich; bei manchen (z.B. "Matrix 300") hat der Code hohe Lokalität, bei anderen durchläuft der Befehlsstrom viele Teile des Programms relativ gleichmäßig. Die Programme wurden vom Steering Committee" von SPEC aus über 50 Vorschlägen ausgewählt. Sie machen zwar einige Betriebssystem-Aufrufe (die Programme sind unter UNIX ablauffähig, wurden jedoch auch mit VMS gemessen), sind aber so CPU-intensiv, daß die Laufzeit für die Betriebssystem-Funktionen vernachlässigt ist.
SPEC selbst nimmt keine Messungen vor, Interessenten können die Benchmarks von SPEC gegen eine Schutzgebühr von 450.- $ auf Magnetband beziehen. Die Mitgliedsfirmen von SPEC können ihre Ergebnisse im SPEC-Newsletter veröffentlichen, wobei alle Daten (benutzte Hardware-Konfiguration, benutzte Compiler usw.) vollständig dokumentiert werden müssen. Die Gefahr einer geschönten Darstellung glaubt man dadurch ausgeschlossen zu haben, daß die SPEC-Benchmarks öffentlich zugänglich und damit alle Messungen jederzeit nachvollziehbar sind; die Veröffentlichung von falschen Daten würde langfristig dem betreffenden Hersteller mehr schaden als nutzen.
Eine kurze Charakterisierung der SPEC-Benchmarks wird in Tabelle 1 gegeben.
Tabelle 1. SPEC-Benchmarks
| Kurzbezeichnung | Charakterisierung | Sprache | Hauptdatentyp |
|---|---|---|---|
| gcc | GNU C-Compiler | C | integer |
| espresso | PLA-Simulator | C | integer |
| spice2g6 | Analoge Schaltkreis-Simulation | Fortran | floating point |
| doduc | Monte-Carlo-Simulation | Fortran | floating point |
| nasa7 | Sammlung von kurzen Numerik-Kernels" | Fortran | floating point |
| li | LISP-Interpreter | C | integer |
| eqntott | Schaltfunktionen-Minimierung, viel Sortieren | C | integer |
| matrix300 | Verschiedene Matrix-Multiplikationen | Fortran | floating point |
| fpppp | Maxwell-Gleichungen | Fortran | floating point |
| tomcatv | Netzwerk-Berechnung, stark vektorisierbar | Fortran | floating point |
Als Maß für die Leistung eines Systems wird für jedes der 10 Programme die SPEC-Ratio" berechnet, das Verhältnis der Laufzeiten einer Referenzmaschine und des Systems. Als Referenzmaschine wurde die VAX 11/780 mit den VMS-Compilern von DEC gewählt. Eine zusammenfassende Charakterisierung, die SPECmark", ist definiert als das geometrische Mittel der (zur Zeit) 10 einzelnen SPECRatios". SPEC war sich darüber im klaren, daß eine solche zusammenfassende Zahl ähnlich der MIPS-Zahl von Vertriebsabteilungen und der Handelspresse gebildet werden würde, und hat deshalb selbst diesen Mittelwert definiert. SPEC rät aber dringen dazu, nicht nur diesen zusammenfassenden Wert, sondern alle 10 Werte zu betrachten, und verpflichtet die teilnehmenden Firmen zu einer Darstellung der Ergebnisse, die alle Rohdaten und alle Relativ-Werte enthält. Der potentielle Kunde soll dann entscheiden, an welchen Werten er sich orientiert, ausgehend von einem Vergleich seines Programmprofils mit den einzelnen SPEC-Benchmarks. Abbildung 1 gibt ein Beispiel für die graphische Darstellung von SPEC-Resultaten; die vollständige Darstellung umfaßt zusätzlich alle Rohdaten und die verwendete Systemkonfiguration.
Beispiel für SPEC-Ergebnisse: MIPS RC3260 (Messung 5/1990)
Seit Herbst 1989 werden laufend Ergebnisse für die SPEC-Benchmarks veröffentlicht. Unter den ersten gemessenen Systemen waren vor allem Workstations und Mikroprozessor-Systeme mit RISC-Prozessoren, inzwischen sind weitere Systeme dazugekommen. Dabei zeigen sich einige Tendenzen, die allgemeine Gültigkeit zu haben scheinen:
- Gegenüber der Referenzmaschine VAX 11/780 - die ja inzwischen schon recht alt ist - haben die neueren RISC-Prozessoren, wie erwartet, eine erhebliche Leistungssteigerung gebracht; dabei wurde die Integer-Leistung in höherem Maße verbessert als die Floating-Point-Leistung.
- Vergleicht man die von den Herstellern angegebenen MIPS-Zahlen mit dem Durchschnittswert der SPEC-Integer-Benchmarks, so sieht man, daß fast alle Hersteller mit der von ihnen angegebenen MIPS-Zahl (die von der Handelspresse meist als Integer-Leistungsverhältnis zur VAX 11/780 aufgefaßt wird) die eigenen Prozessoren in einem zu guten Licht erscheinen lassen, wobei allerdings erhebliche Unterschiede zwischen den einzelnen Herstellern und Produktlinien bestehen.
- Die zehn Einzelwerte streuen teils stärker, teils weniger stark um den Mittelwert, die SPECmark; dabei gibt es im allgemeinen beim LISP-Interpreter ("li") und bei manchen Floating-Point-Benchmarks die größten Schwankungen.
- "Superskalare" Prozessoren, die durch parallele Funktionseinheiten mehr als einen Befehl pro Zyklus anstoßen können, realisieren ihren Geschwindigkeitsvorteil überwiegend bei Floating-Point-Benchmarks, und zwar bei denen, die vektorisierbaren Code enthalten. Offenbar läßt sich die Parallelarbeit - jedenfalls bei den gegenwärtigen Prozessor-Designs, wo es vor allem um Parallelarbeit zwischen Integer- und Floating-Point-Einheit geht - im wesentlichen nur bei Programmen, die eine sehr reguläre Code-Struktur haben, in signifikantem Maß nutzen; dann aber trägt sie zu einer erheblichen Leistungssteigerung bei.
Trotz der kurzen Zeit seit Beginn der Arbeit von SPEC haben sich die Benchmarks als ein nützliches Mittel zum Leistungsvergleich von Computersystemen vor allem im Workstation-Bereich erwiesen; sie sind unbestreitbar ein Fortschritt im Gebiet Benchmarking. Trotzdem kann es auf bei ihnen Probleme geben:
- Die Benchmark-Programme müssen zu einem frühen Zeitpunkt "eingefroren" werden, damit alle mit demselben Programm arbeiten. Vor allem manche FORTRAN-Benchmarks können aus Code bestehen, der schon recht alt ist ("dusty deck") und neuere Erkenntnisse des Software Engineering noch nicht berücksichtigt (z.B. Vermeiden der früher relativ "teuren" Prozeduraufrufe, Benutzung von globalen statt lokalen Variablen); "docuc" ist hierfür ein Beispiel. Damit sind sie zwar oft für die in Rechenzentren derzeit ablaufenden Programme repräsentativ, es wäre aber bedauerlich, wenn Rechnerarchitekten sich bei ihren Optimierungs-Überlegungen auf dem Weg über die SPEC-Benchmarks von veralteten Programmier-Praktiken leiten ließen.
- Auch für einzelne der SPEC-Benchmarks kann es Compiler-Optimierungen geben, die sie besonders beschleunigen; und bei der Größe der Programme sind solche Benchmark-bezogenen Optimierungen wesentlich schwerer zu entdecken als bei den kurzen synthetischen Benchmarks. Dies ist nur dann unproblematisch, wenn auch "normale" Programme von diesen Optimierungen profitieren.
- In der Handelspresse zeigt sich trotz der guten Absichten von SPEC eine bedauerliche Tendenz, sich nur auf den Mittelwert, die SPECmark, zu konzentrieren. Dann wird, wie das obige Beispiel von der besonderen Eignung superskalarer Prozessoren für vektorisierbaren Code zeigt, die Auswahl der Benchmarks besonders wichtig; eine "geschickte" Auswahl kann Prozessoren in der Durchschnittswertung besser oder schlechter erscheinen lassen.
Die beim ersten Release in der SPEC-Suite enthaltenen Benchmarks decken nur den Bereich der CPU-intensiven Programmierung ab; man hat sich für den Start der SPEC-Aktivitäten auf das beschränkt, was relativ schnell machbar war. Release 2.0 wird neben weiteren CPU-Benchmarks auch I/O-intensive Programme enthalten. SPEC plant, weitere Benchmarks z.B. für Graphik-Anwendungen und für Multiprozessor-Systeme zu sammeln und zu veröffentlichen; außerdem ist geplant, die Benchmark-Sammlung auch auf weitere Programmiersprachen (COBOL, Ada) zu erweitern.
Adresse von SPEC:
SPEC-System Performance Evaluation Cooperative
(Kim Shanley, Secretary)
c/o Waterside Associates
39150 Paseo Padre Pkwy, Suite 350,
Premont, CA 94538, USA
Telefon: +1-415-792-2901; Fax: +1-415-792-4748
shanley@cup.portal.com
Literatur
- Serlin, O.: MIPS, Dhrystones and Other Tales, Datamation 32, 112-118 (1988)
- Weicker, R.P.: An Overview of Common Benchmarks. IEEE Comput. (im Druck)
- Uniejewski, J.: Characterizing System Performance Using Application Level Benchmarks. Proc. BUSCON Conf., Malborough (Mass.), Sept. 1989, p. 159-167
- SPEC Benchmarks Suite Release 1.0. SPEC Newslett. 2 (3), 3-4 (1990)
Autor und Copyright
R. Weicker (München)
© 1990 Informatik Spektrum, Springer-Verlag Berlin Heidelberg