Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

15.02.1991 - 

Leistungsmessung für RISC- und CISC-Prozessoren Teil 3 und Schluß

Für die Leistungsfähigkeit von Systemen zählen nicht nur MIPS

Zwei Argumente werden bei der Diskussion der Vorteile von RISC-Architekturen immer wieder ins Feld geführt: hohe Rechenleistung und einfacher Entwurf. Mit dem Aufkommen hochleistungsfähiger RISC-Workstations entfachte auch wieder Diskussion um Leistungsmessungen (Benchmarks) von Rechnerarchitekturen. Im dritten Teil befaßt sich der Autor ausführlich mit der Initiative der System Performance Evaluation Cooperative (SPEC), zu allgemeingültigen Testverfahren zu gelangen.

Die Darstellung im vorigen Abschnitt hat zwei wesentliche Nachteile der bisher verwendeten "Standard-Benchmarks" erkennen lassen:

- Bei der Kürze der Programme fällt es Compiler-Autoren verhältnismäßig leicht, die Codierung 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, werden sie fast vollständig ans dem Cache heraus ausgeführt, das Speichersystem wird außer im Fall Linpack für den Datenbereich nicht realistisch getestet.

Aus diesem Grund haben sich unter dem Namen "System Performance Evaluation Cooperative" (SPEC) - nach einer Initiative vor allem von RISC-Herstellern - fast alle bedeutenden Rechnerhersteller zusammengeschlossen, 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.

SPEC hat sich zur Aufgabe gesetzt, große Anwendungsprogramme zu sammeln und in einer normierten Form als Benchmark-Suite zur Verfügung zu stellen. Dies ist kein triviales Unterfangen, da viele Programme, die vorher neben den kurzen Benchmarks für Leistungsmessungen verwendet wurden (zum Beispiel 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 zehn Programme mit zusammen etwa 150 000 Zeilen Quellcode. Vier der Programme sind in C geschrieben, sechs in Fortran. Auch die Charakteristiken der Programme sind unterschiedlich; bei manchen (zum Beispiel "matrix 300") hat der Code eine hohe Lokalität, bei anderen durchläuft der Befehlsstrom viele Teile des Programms relativ gleichmäßig.

Die Programme wurden vom "Steering Committee" der 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), sie sind aber so CPU-intensiv, daß die Laufzeit für die Betriebssystem-Funktionen vernachlässigbar ist.

SPEC selbst nimmt keine Messungen vor, Interessenten können die Benchmarks von SPEC gegen eine Schutzgebühr von 450 Dollar auf Magnetband beziehen. Die Mitgliedsfirmen von SPEC haben die Möglichkeit ihre Ergebnisse im "SPEC-Newsletter" zu veröffentlichen, wobei alle Daten (benutzte Hardware-Konfiguration, benutzte Compiler etwa) 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 ausführlichere Beschreibung der SPEC-Tests findet sich im "SPEC Newsletter" (Volume 2, Nummer 3, Sommer 1990).

Als das Maß für die Leistung eines Systems wird für jedes der zehn Programme die "SPEC Ratio" berechnet, der Kehrwert des Laufzeit-Verhältnisses zu einer Referenzmaschine. Als diese Referenzmaschine wurde die VAX 11/780 mit den VMS-Compilern von DEC gewählt. Eine zusammenfassende Charakterisierung, die "SPEC-Mark", ist definiert als das geometrische Mittel der zur Zeit noch zehn einzelnen "SPEC Ratios".

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 dringend dazu, nicht mir diesen zusammenfassenden Wert, sondern alle zehn Werte zu betrachten, und verpflichtet die teilnehmenden Firmen zu einer Darstellung der Ergebnisse, die alle Rohdaten und alle einzelnen 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.

Seit Herbst 1989 werden ins "SPEC Newsletter" 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 auch weitere Systeme dazugekommen. Dabei zeigten 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 dein 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 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 solchen Programmen, die eine sehr reguläre Code-Struktur haben, in einem signifikanten 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 stellen unbestreitbar einen Fortschritt im Gebiet Benchmarking dar. Trotzdem kann es auch bei ihnen problematische Punkte gehen:

- Die Benchmark-Programme müssen zu einem frühen Zeitpunkt "eingefroren" werden, damit alle mit demselben Programm arbeiten. Vor allein manche Fortran-Benchmarks können aus Code bestehen, der schon recht alt ist und neuere Erkenntnisse des Software Engineering noch nicht berücksichtigt (zum Beispiel Vermeiden der früher relativ teuren Prozeduraufrufe, Benutzung von globalen staat lokalen Variablen); "Doduc" 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 Rechnerarchitekturen 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. Bei der Größe der Programme sind solche Benchmark-bezogene Optimierungen wesentlich schwerer zu entdecken als bei den kurzen synthetischen Benchmarks. Dies ist nur dann unproblematisch, wenn "normale" Programme von diesen Optimierungen in gleicher Weise profitieren.

- In der Handelspresse zeigt sich trotz der guten Absichten von SPEC (Veröffentlichung aller Zahlen) eine bedauerliche Tendenz, sich nur auf den Mittelwert, die SPEC-Marks zu konzentrieren. Dann wird, wie das obige Beispiel von der besonderen Eignung der superskalaren 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 zum Beispiel für Grafik-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.

Benchmark-Resultute statt MIPS-Angaben

Als Resultat aus der Diskussion von Leistungsaspekten und Benchmarks kann man, im Sinne einer Verbraucherberatung, dem Rechnerkunden mehrere Ratschläge geben:

- MIPS-Angaben ohne Erläuterung, wie sie gewonnen wurden, sollten äußerst kritisch betrachtet werden. Vor allem Angaben von "Peak MIPS" stellen nichts anderes als eine andere Benennung der Taktfrequenz dar (wenn der schnellste Befehl in einem Zyklus ausführbar ist). Sie bringen daher keine neue Information, wenn nicht gleichzeitig gesagt wird, wie groß im Durchschnitt der Anteil der Befehle ist, die so schnell ausgeführt werden können.

MIPS-Angaben, die in Wirklichkeit einen Faktor relativ zur VAX 11/780 darstellen, sind besser, wenn man weiß, welche, Benchmark-Programme, welche Programmiersprachen und welche Compiler zugrunde liegen. Die SPEC-Zahlen erfüllen diese Voraussetzungen sehr gut. - MFLOPS-Angaben sind natürlich nur für ihren Bereich, die Numerik - ein besserer Anhaltspunkt, wenn gesichert ist, daß sie auf der Grundlage eines Standard-Benchmarks gewonnen wurden, und wenn dieser Benchmark bei allen zu vergleichenden Prozessoren derselbe ist.

Scharf auseinanderhalten muß man "Linpack-MFLOPS", dazwischen liegt selbst bei einem speziell für den Floating-Point- und Grafik-Markt vorgesehenen Prozessor wie dem Intel i860 ein Faktor 8.

- Benchmark-Resultate sind immer besser als MIPS-Angaben, man sollte aber unbedingt mehrere Benchmarks verwenden. Der beste Benchmark ist sicher die eigene Anwendung; dies wird sich aber nicht immer realisieren lassen, da der Aufwand zum Installieren eines größeren Programms auf mehreren Rechnern nicht unerheblich ist.

Außerdem wird selbst dann, wenn eigene Anwendungen zum Vergleich herangezogen werden, der Bereich "Betriebssystem" nicht erfaßt, und Messungen zeigen, daß ein Anteil von 50 Prozent der Zeit für Betriebssystemfunktionen nicht unrealistisch ist.

- Bei allen Benchmarks, vor allem bei synthetischen Benchmarks, sollte man möglichst genaue Angaben über die Meßbedingungen verlangen: Taktfrequenz, Speicher-Zugriffszeiten,

Cache-Größe, Größe der Datenbereiche, Programmiersprache, Compiler-Version, Laufzeitsystem, verwendete Optimierungen. Davon, wie stark der Compiler zur Leistung beiträgt, und ob er ein bestimmtes Benchmark-Programm besonders stark optimiert, überzeugt man sich am besten, indem man ein Maschinencode-Listing des Benchmarks studiert.

Die Welt der Leistungsmessung läßt heute etwas mehr Hoffnung zu als noch vor einigen Jahren, es gibt die folgenden Tendenzen:

- Trotz der Schwierigkeit, auf diesem heiklen Gebiet Hersteller zu einer Zusammenarbeit zu bringen, ist dies doch bei SPEC und, für transaktionsorientierte Datenverarbeitung, beim "Transaction Processing Council" (TPC) geschehen.

- Zunehmend werden große Programme als Benchmarks verwendet; im Bereich der CPU-Architektur und -Implementierung (einschließlich Compiler-Optimierung) werden die SPEC-Benchmarks stark an Bedeutung gewinnen.

- Es erscheint notwendig, die Leistung stärker differenziert darzustellen als bisher üblich. 24 verschiedene MFLOPS-Werte, wie sie die "Livermore Fortran Kemels" liefern, sind sicher eine Überforderung für das durchschnittliche Management (sie sind nur vom Experten richtig interpretierbar), die Beschränkung auf eine MIPS-Zahl oder auch Specmark ist aber sicher viel zu wenig.

Bei den SPEC-Benchmarks wird zu Recht gefordert, daß alle Einzel-Ergebnisse genannt werden. Als zusammenfassende Werte, die etwas mehr aussagen als die globale Specmark-Zahl, haben sich die Durchschnittszahlen für die Integer- und die Floating-Point-Benchmarks eingebürgert. Man sollte aber noch stärker vom Anwendungsgebiet her aufschlüsseln, etwa nach dem Kriterium vektorisierbar, nicht vektorisierbar, großer/kleiner Datenbereich, hohe/niedrige Code-Lokalität.

- Es wird (hoffentlich) zunehmend schwieriger für einen Hersteller, unspezifizierbare MIPS-Zahlen zu nennen; mit besserem Wissen über Leistungsmessung und Benchmarks werden Anwender fundierte Angaben verlangen.