Zwei Argumente werden bei der Diskussion der Vorteile von RISC-Architekturen immer wieder ins Feld geführt: hohe Rechenleistung und einfacher Entwurf. Das Aufkommen hochleistungsfähiger RISC-Workstations entfachte wieder die Diskussion um Leistungsmessungen (Benchmarks) von Rechnerarchitekturen. In der folgenden CW-Serie soll dieses Thema ausführlich zur Sprache kommen.

Seit Beginn der Diskussionen um RISC-Architekturen wird die Geschwindigkeit, also die Rechenleistung, als der wesentliche Vorteil des RISC-Konzepts genannt. Dazu kommt der einfachere Entwurf (gute Eignung für VSLI), der indirekt (schnellere Nutzung neuer Technologie) wieder zur Geschwindigkeit beitragen kann.

So ist es kein Wunder, daß die Debatte um Leistungsmessungen für CPUs mit dem Aufkommen von RISC-Architekturen neu belebt wurde: Es ist auch kein Zufall, daß eine der wesentlichen Initiativen auf diesem Gebiet, die System Performance Evaluation Cooperative (SPEC) maßgeblich von RISC-Herstellern ausging (vergleiche CW Nr. 24 vom 15. Juni 1990, Seite 23 "Workstations der IBM...").

Im vorliegenden Beitrag wird zunächst auf Faktoren der CPU-Leistung allgemein eingegangen, und es werden die traditionell üblichen MIPS-Leistungsangaben kritisch betrachtet. Dann werden einige "Benchmark-Programme", mit denen man die Leistung genauer bestimmen kann, näher besprochen. Ziel ist, im Sinne einer "Verbraucherberatung" für RISC- und CISC-Anwender die nicht wenigen, zum Teil oft übersehenen Tücken von Leistungsangaben sichtbar zu machen. Schließlich wird auf die SPEC-Benchmarks, eine neuere Initiative zu besserer Leistungsmessung, näher eingegangen. In neueren Texten zur Rechnerarchitektur (5) findet sich oft die folgende von John Hennessy als "iron law of performance" bezeichnete Formel:

Dabei sind

1) Taktfrequenz des Prozessors

2) Anzahl der Befehle für ein typisches Programm

3) durchschnittliche Anzahl der Taktzyklen pro Befehl.

Frühere Architekturen (CISC-Architekturen) hatten versucht, durch mächtigere Befehle den Faktor (2) zu verkleinern und dadurch die Leistung zu erhöhen. Im Extremfall führte das zur Sprachen-Maschine (HLL-Maschine), für die als Ziel angesehen wurde, daß jeder Anweisung oder zumindest jeder Operation (Addition, if-Anweisung, Prozeduraufruf) nicht mehr als ein Befehl der Maschine entspricht. Es hat sich aber gezeigt, daß der Gewinn an Geschwindigkeit doch nicht so groß ist wie erhofft; komplexe Operationen bleiben auch bei der Ausführung durch Mikroprogramme komplex und damit zeitaufwendig.

RISC-Architekturen versuchen, die clock speed zu vergrößern und die Zyklen pro Instruktion möglichst nahe an 1 heranzubringen (das heißt, in fast jedem Zyklus wird ein neuer Befehl angestoßen). Während die clock speed - unabhängig vom Architekturprinzip - im wesentlichen mit fortschreitender Technologie größer wird, ist für die Anzahl der Zyklen pro Instruktion das Prinzip der RISC-Architektur ganz wesentlich:

Wenn alle Befehle einfach und gleichartig aufgebaut sind (einfache Decodierung), kann ein effizientes Pipelining besser realisiert werden, und die Aussichten sind wesentlich besser, daß trotz hoher Taktfrequenz in nahezu jedem Zyklus ein Befehl angestoßen wird.

Eine gewisse Vergrößerung der auszuführenden Befehle wird dabei in Kauf genommen; durch optimierende Compiler (Eliminieren von überflüssigen Befehlen, zum Beispiel von redundanten Load-Befehlen) wird jedoch erreicht, daß die auszuführenden Instruktionen trotzdem nicht zu stark wachsen.

Der Quotient von 1 und 3 aus der obigen Formel ergibt genau die MIPS im wörtlichen Sinn ("Million Instructions per Second"). Weil für die Rechengeschwindigkeit eines echten Programms aber noch der Faktor von 2 eingeht und weil gerade er für RISC- und für CISC-Prozessoren sehr unterschiedlich sein kann, ist offensichtlich, daß die MIPS-Angabe im wörtlichen Sinn als Charakterisierung der Leistung für den Anwender unbrauchbar ist.

Es hat sich deshalb vielerorts eingebürgert, zwar die Bezeichnung "MIPS" beizubehalten, ihr aber einen neuen Sinn zu geben: Man geht von der Annahme aus, daß der früher viel gebrauchte DEC-Rechner VAX 11/780 bei typischen Programmen wesentlich weniger als eine Million Befehle pro Sekunde ausführt. Man mißt nun die Leistung des eigenen Prozessors, vergleicht mit der VAX 11/780 und nennt den sich ergebenden Faktor die MIPS-Zahl. Dieses Verfahren ist, wenn der Vergleich fair ist (Auswahl repräsentativer Programme, Compiler vergleichbarer Qualität), nicht zu beanstanden. Man sollte aber das Ergebnis lieber "VAX-Faktor" oder ähnlich nennen und nicht "MIPS".

Insgesamt findet man die folgenden De-facto-Definitionen, wenn Hersteller die Leistung ihrer Prozessoren in MIPS angeben:

- MIPS im wörtlichen Sinn (Millions of Instructions per Second), oft auch "native MIPS" genannt. Meist bleibt unklar, welches Programm zugrunde liegt und wieviele Befehle pro HLL-Statement durchschnittlich erzeugt werden.

- "Peak MIPS": Besonders unsinnige Angabe. Wenn, wie bei den meisten Prozessoren, die schnellsten Befehle einen Zyklus brauchen, ist dies nichts anderes als die Taktfrequenz.

- "EDN-MIPS", "Dhrystone-MIPS" und andere: Dies könnte heißen: MIPS im wörtlichen Sinn, wenn ein ganz bestimmtes Programm läuft. Wird aber meist in der Bedeutung "VAX MIPS" verwendet, mit dem genannten Programm als Maßstab.

- "VAX MIPS", manchmal auch "VUPS" genannt (VAX Units of Performance): Leistungsfaktor relativ zur VAX 11/780. Wenn DEC selbst von VUPS spricht, liegt eine definierte DEC-interne Auswahl von Programmen zugrunde, die auch Floating-Point-Programme enthält.

- "SPEC MIPS": Vermutlich wird die neue Maßzahl "SPEC-mark" bald auch als MIPS-Zahl bezeichnet werden, da sie ebenfalls als Leistungsfaktor relativ zur VAX 11/780 definiert ist.

- "MIPS' ohne nähere Angabe: Hier bleibt nichts als die Interpretation "Marketing Instructions per Second", "Magical Indication of Processor Speed" oder eine andere der scherzhaften Deutungen.

Insgesamt jedoch kommt man nicht um eine Mittelwert-Bildung herum, was notwendigerweise zur Frage nach repräsentativen Programmen, das heißt nach Benchmark-Programmen, führt.

Benchmarks sollten repräsentativ sein

"Benchmark" heißt wörtlich "Festpunkt", und in gewissem Sinn kann jedes Programm, das man zu Vergleichszwecken auf mehreren Rechnern laufen läßt, als solcher Anhaltspunkt dienen. Im engeren Sinn versteht man aber unter einem Benchmark-Programm ein Programm, das nicht nur auf mehreren Maschinen zu Vergleichszwecken ablaufen kann, sondern das auch repräsentativ ist für einen gewissen Anwendungsbereich. Man unterscheidet dabei zwischen den Kategorien

- System-Benchmarks: Das Programm enthält, eventuell indirekt, Aufrufe an das Betriebssystem, zum Beispiel zum Zugriff auf Dateien oder zur Ein- und Ausgabe. Es wird also die Systemleistung eines Rechners gemessen.

- CPU-Benchmarks: Das Programm enthält keine Aufrufe an das Betriebssystem, es wird nur die interne Verarbeitungsgeschwindigkeit (CPU, Speichersystem) gemessen. Solche Benchmarks liegen im Normalfall in einer höheren Programmiersprache vor (andernfalls kann man unterschiedliche Prozessoren nur begrenzt vergleichen), so daß immer die Qualität der Codeerzeugung des Compilers mitgemessen wird. Eigentlich sollte man diese Programme deshalb CPU-CompiIer-Benchmarks nennen.

Während für Endkunden System-Benchmarks das sind, was sie eigentlich wollen, sind für Architekturüberlegungen im Umfeld der RISC-Thematik CPU-Benchmarks interessant; mit ihrer Hilfe kann man zu messen versuchen, ob RISC-Architekturen wirklich, wie angestrebt, eine höhere Verarbeitungsleistung bringen als bisher übliche Architekturen.

In der Landschaft der CPU-Compiler-Benchmarks sollte man drei Gruppen unterscheiden:

- Kleinere, meist synthetische Benchmarks, die als "Industrie-Standard" gelten: Whetstone (1), Dhrystone (9,10), Linpack (2,3).

- Umfangreichere Benchmark-Sammlungen für numerische Aufgaben (große Floating-Point-Benchmarks): Livermore Fortran Kemels (6), Perfect Club Benchmark, Nasa Kemels.

- SPEC Benchmarks (8), eine Sammlung von 10 großen, CPU-intensiven Programmen (4 Integer, 6 Floating Point).

Begrenztheit der Aussage muß bewußt gemacht werden

In diesem Beitrag möchte ich vor allem auf die ersten Tests und die SPEC-Benchmarks eingehen, die numerischen Testläufe wegen der besonderen Thematik und wegen des begrenzten Platzes aber nur erwähnen.

Die Benchmark-Programme Whetstone, Dhrystone und Linpack haben den Vorteil, daß sie nicht allzu groß sind, deshalb relativ leicht auf eine große Zahl von Maschinen portiert werden können, trotzdem aber eine gewisse Repräsentativität für ihre Anwendungsbereiche beanspruchen können. Dies erklärt auch ihre große Popularität. Deshalb lohnt es sich, über ihre Eigenschaften genauer Bescheid zu wissen, wobei man sich allerdings über die Begrenztheit ihrer Aussagekraft im klaren sein muß - ihre genauere Betrachtung zeigt, was sie messen und was nicht.

(wird fortgesetzt)

Literatur

1) Cumos, H.J., and Wichmann, B.A.: A Synthetic Benchmark The Computer Journal 19,1 (1976), S. 43-49

2) Dongarra, Jack J.: The LINPACK Benchmark: An Explanation Supercomputer '87. Seminar, June 12-13, 1987, Mannheim, S. 160-176 und Evaluation Supercomputers (Conference Proceedings, London, June 1-3, 1988), Uxbridge (UK) 1988, S. 150-167

3) Dongarra, Jack J.: Performance of Various Computers Using Standard Equation Software in a FORTRAN Environment ACMM Computer Architecture News 18,1 (March 1990), S. 17-31

4) Funk, Bud: RISC and CISC Benchmarks and Insights Unisys World, Jan.1989, 11-12 and 14 5) Henessy, John und Patterson, David: Computer Architecture: A Quantitative Approach. Morgan Kaufmann Publishers, San Mateo, Ca.

6) McMahon, Frank H.: The Livermore Fortran Kemels: A Computer Test of the Numerical Performance Range Lawrence Livermore National Laboratory Livermore (Ca), Technical Report UCRL-53333745, Dec. 1986, S. 179

7) MIPS Computer Systems Inc.: Performance Brief, CPU Benchmarks Issue 3.9 January 1990, S. 35

8) Uniejewski, Joseph: Characterizing System Performance Using Application Level Benchmarks Proceedings of the BUSCON Conference, Malborough (Ma), Sept. 1989,159-167

9) Weicker, Reinhold P.: Dhrystone: A Synthetic Systems Programming Benchmark Communications of the ACMM 27,10 (Oct.1984), S.1013-1030

10) Weicker, Reinhold P.: Dhrystone Benchmark: Rationale for Version 2 and Measurement Rules SIGPLAN Notices 23,8 (Aug. 1988), S. 49-62

11) Weicker, Reinhold P.: An Overview of Common Benchmarks in: "Computer" (IEEE), 23, 12 (Dez. 1990) S. 65 bis 75.