Ketzerische Anleitungen für Benchmark-Fanatiker

Zwölf Tips zur Beschönigung von Supercomputer-Benchmarks

30.08.1991

Immer wieder werden sie in den Mittelpunkt gestellt: Benchmarkdaten, die die Leistungen eines Systems belegen sollen. Daß es hier Tricks gibt, diese zu schönen oder zu manipulieren, mag bekannt sein. Daß man solche Trick heutzutage besonders bei Parallelrechnern anwendet, ist kein Wunder. Fritz Berger* faßt zwölf nicht ganz ernstgemeinte "Vorschläge" eines US-Spezialisten zum Thema Benchmarking bei Supercomputern zusammen.

Unter den Titel "Twelve ways to fool the masses when giving performance results on parallel computers" hat David H. Bailey von der Numerical Aerodynamic Simulation (NAS) Systems Division am Nasa Ames Research Center in Moffet Field seinen technischen Bericht (RNR Technical Report RNR-91-020 vom 11. Juni 1991) gestellt. Die zwölf "Vorschläge" sind typisch für die Situation im Vektor- und Parallelrechner-Markt. Gerade der Bereich des Benchmarking ermöglicht so viele Interpretationen und Auslegungen, daß beinahe jedes gewünschte Ergebnis herausgelesen werden kann - und von vornherein erreicht werden kann. Trotz der humorigen und lockeren Darstellung sollte man die Ernsthaftigkeit hinter diesen Aussagen nicht übersehen: Wie oft wurden Anwender schon durch derartige Techniken hinters Licht geführt.

1. Ergebnisse in 32-Bit-Genauigkeit reichen aus, niemals die 64-Bit-Resultate angeben.

Alle aus der Szene wissen, daß es äußerst schwer ist, beeindruckende Ergebnisse in 64-Bit-Gleitkomma-Arithmetik zu erzielen. Manche Rechnersysteme bieten nicht einmal 64-Bit-Hardware! Darum sollte man ausschließlich die 32-Bit-Ergebnisse angeben, diese Tatsache aber tunlichst verschweigen.

Bloß nicht die Zuhörer irritieren

Noch wirkungsvoller ist es, wenn man diese 32-Bit-Ergebnisse mit 64-Bit-Zahlen auf anderen Systemen vergleicht - nur keine Hemmungen! Reicht die geringere Genauigkeit für die eigene Anwendung nicht aus, so sollte man das verschweigen, um die Zuhörer oder Leser mit solchen Details nicht zu verwirren.

2. Präsentiere nur Leistungszahlen von inneren Programmkernen und stelle diese Ergebnisse als Leistung der gesamten Anwendung hin.

Bei komplexen wissenschaftlichen Anwendungsprogramme ist es sehr schwer, Höchstleistungen zu erzielen. So ziehen die Ein- und Ausgabe, die Initialisierung der Anwendung (Datenverteilung), Kommunikation und weitere Faktoren die Gesamtleistung dramatisch nach unten - gemessen vom Beginn bis zum Ende der Anwendung. Die Lösung dieses Dilemmas: Präsentation der Leistung von inneren Kernen. Das sind Programmteile und DO-Loops, die am häufigsten durchlaufen werden. Im Vortrag muß man dann überzeugend den Eindruck erwecken, daß diese Ergebnisse der Leistung der vollständigen Anwendung entsprechen.

3. Heimlich sollte man Assembler-Code, Bibliotheksroutinen und maschinennahe Sprachkonstrukte verwenden.

Oft ist es extrem schwer, auf den Parallelrechnern gute Leistungen aus Standard-Fortran- oder C-Programmen herauszuholen. Hier spielen Compiler-Schwächen bei der Autoparallelisierung oder der Erkennung paralleler Konstrukte eine große Rolle. Der Programmcode wird noch nicht optimal umgesetzt. Da sollte man sich nicht scheuen, Assembler-Kerne, Bibliotheksunterprogramme oder Kommunikationsroutinen auf niederer Ebene einzubinden. Die Verwendung muß man ja nicht erwähnen. Der Zuhörer oder Leser könnte sonst "irrtümlich" meinen, daß Assembler-Codierung zwingend notwendig ist, um respektable Leistung zu erzielen.

4. Skaliere die Problemgröße mit der Zahl der Prozessoren, verschweige aber diese Tatsache.

Bei wachsender Prozessorzahl wird die Leistungssteigerung immer geringer. Ein Ausweg bietet sich auch hier an: Man vergrößert das Problem mit der Zahl der Prozessoren. Das darf man aber niemals bei der Präsentation der Ergebnisse erwähnen! Wird diese Tatsache möglicherweise aufgedeckt, erheben sich äußerst unangenehme Fragen zur Effizienz der Implementierung des Programms.

5. Projiziere die Leistungsdaten auf ein voll ausgebautes System.

Nur wenige Unternehmen, Hochschulen oder Großforschungseinrichtungen können sich ein voll ausgebautes Parallelrechner-System leisten. Diese Rechner kosten nämlich viele Millionen Mark. Leider beeindruckt die Leistung kleinerer Rechnersysteme die Zuhörer wenig. Die Lösung dieser Dilemmas ist eine lineare Übertragung, sprich: Abbildung der Ergebnisse auf das maximale System.

Machen Sie einen Cray-Rechner flügellahm

Diese Resultate müssen mutig und überzeugend vorgetragen werden. Es untergräbt schließlich die eigene Autorität, wenn man nur auf Minimalsystemen gearbeitet hat.

6. Vergleiche deine Ergebnisse mit skalarem, nichtoptimierten Code auf einer Cray.

Selbstverständlich beeindruckt man die Zuhörerschaft, wenn das eigene Programm um einige Faktoren schneller als auf einer Cray läuft, die ja der am weitesten verbreitete Supercomputer auf der Welt ist. Unglücklicherweise laufen viele Anwendungen schon mit geringen Tuning-Maßnahmen sehr schnell auf einer Cray oder einer verwandten Architektur. Darum darf man auf keinen Fall das Programm auf der Cray oder ähnlichen Rechnern verbessern. Man sollte unbedingt von Vektorisierungs-Direktiven (CDIR) Abstand nehmen. Sind irgendwelche im Programm vorhanden - gleich raus damit. In außergewöhnlichen Fällen muß man sogar zum letzten Mittel greifen und die Vektorisierung auf der Cray durch einen Befehl oder Parameter abschalten.

Direkte Laufzeitvergleiche mit veralteten Programmen

Übrigens bremsen Bankkonflikte die Rechenleistung einer Cray, also auf Daten im Abstand von größeren Zweierpotenzen zugreifen (Stride 2,4,8 etc). Daß Multitasking und Autotasking auf der Cray vermieden werden muß, ist doch jetzt schon selbstverständlich.

Im Bericht muß natürlich darauf hingewiesen werden, daß die Leistungsdaten eines einzelnen Cray-Prozessors, mit dem man die eigenen Ergebnisse vergleicht, einem voll ausgebauten 50-Millionen-Mark-System entsprechen.

7. Bei direkten Laufzeitvergleichen ein veraltetes Programm oder einen obsoleten Rechner verwenden.

Direkte Laufzeitvergleiche können sehr peinlich sein, insbesondere dann, wenn das parallele Programm erheblich langsamer ist als auf einem konventionellen Rechner. Da bietet es sich an, auf dem konventionellen Rechner ein veraltetes Programm laufen zu lassen und diese Ergebnisse mit den parallelen zu vergleichen. Noch besser ist es, auch noch einen obsoleten Rechner zu verwenden. Mit dessen veraltetem oder obsoleten Compiler müßte es schon hinhauen mit den Ergebnissen. Ganz hervorragend eignet sich die Aussage: hundertmal schneller als eine VAX 11/780. Auch der Vergleich mit langsameren Parallelrechnern ist sinnvoll - nicht zu vergessen das Motto: Wir sind zwar langsam, doch schneller als andere.

8. Bei Mflops-Angaben die parallelen Operationen zählen, nicht die der besten sequentiellen Implementierung.

Mflops-Raten sind mies bei parallelen Anwendungen

Es ist ja bekannt, daß die Mflops-Raten von parallelen Programmen nicht gerade berauschend sind. Zum Glück kann man diese Ergebnisse "schönen". Sehr effektiv ist es, die Rechenoperationen auf der Grundlage des aufgeblähten parallelen Programms zu zählen. Dort werden erheblich mehr Rechenoperationen durchgeführt als in der besten sequentiellen Umsetzung.

Durch Einfügen einiger unnützer Schleifen lassen sich dann noch weitere Millionen Operationen berücksichtigen. Bei der Endabrechnung steigt dann die Mflops-Rate, und schon findet man das parallele Programm auf der Siegerstraße.

9. Als Leistungsmaß nur Prozessorauslastung, parallele Beschleunigung oder Mflops pro Dollar angeben.

Wie oben schon diskutiert, ist es wenig nützlich, Laufzeitvergleiche oder Mflops von parallelen Programmen mit denen auf konventionellen Supercomputern zu vergleichen. Andere Leistungsmaße müssen her! Hervorragend eignet sich die Größe "Prozessorauslastung". Da ist doch die Fachwelt beeindruckt, wenn alle Prozessoren über die gesamte Zeit fast zu 100 Prozent ausgelastet sind. Daß sie gerade mit Synchronisation oder Kommunikation beschäftigt sind, interessiert doch nur den Kleingeist. Sehr gut ist als Maß auch die "parallele Beschleunigung" geeignet. Natürlich erreicht man eine lineare Beschleunigung, indem man dafür sorgt, daß die Einprozessor-Version hinreichend langsam läuft. Hier hilft es, auch in der Einprozessor-Version Kommunikations- und Synchronisationselemente zu verwenden, obwohl das auf einem Prozessor gar nicht benötigt wird. Als dritte Statistik empfiehlt der Fachmann Mflops pro Dollar. Man sollte diese Zahl aber nicht mit "sustained Mflops pro Dollar" verwechseln. Diese Größe eignet sich auf Grund der meist schwachen Leistung neuer Systeme wenig,

10. Passe den parallelen Algorithmus an die Architektur an.

Jedermann weiß, daß gerade bei Parallelrechnern algorithmische Änderungen nötig sind, um höhere Leistung zu erzielen. Es ist also ein Verfahren auszusuchen, das zwar hohe Mflops-Raten erreicht, für das Problem aber wenig sinnvoll ist.

Zuhörer wundern sich über ungeeignete Meßverfahren

So bringen explizite Gleichungslöser bei Parallelrechnern sehr hohe Mflops-Ergebnisse, obwohl die Konvergenz erheblich schlechter ist als bei impliziten oder Mehrgitterverfahren. Diese Tatsache muß man herunterspielen, andernfalls wundert sich die Zuhörerschaft, daß man ein derart ungeeignetes Verfahren gewählt hat.

11. Zur Laufzeitmessung nehme man einen dedizierten Parallelrechner und einen voll ausgelasteten konventionellen Rechner.

Es gibt viele Möglichkeiten, mit der Superleistung eines parallelen Programms zu glänzen. Ein Tip: Man sollte viele Läufe auf beiden Rechnerarchitekturen durchfuhren. Selbstverständlich wählt man nun für den Parallelrechner die beste Zeit und für das konventionelle System die schlechteste. Eine andere Möglichkeit besteht darin, einen voll belasteten konventionellen Rechner mit einem dedizierten parallelen zu vergleichen - dann sprechen die Ergebnisse schon für sich. Kommen kritische Fragen aus dem Publikum, warum der konventionelle Rechner voll, der parallele aber leer ist, sollte man sich tunlichst einem interessanteren und wichtigeren Thema zuwenden.

12. Bei Versagen aller Tips helfen bunte Bilder, hübsche Videos und Stillschweigen über Leistungsdaten.

Gegen hartnäckige Frager hilft eine Videovorführung

Manchmal stellen die Zuhörer unmögliche Fragen - diese Personen haben keinen Respekt vor Experten auf diesem Gebiet. Wenn man Pech hat und Opfer solcher Querulanten wird, gibt es einen Ausweg: Beende die technischen Ausführungen und zeige ein Video. Die Zuhörerschaft liebt bunte Bilder. Das hilft sehr gut, von grundsätzlichen technischen Fragen abzulenken.

Sicherlich hat jetzt so mancher Leser festgestellt, daß diese Tips mit der Wirklichkeit in vielen Firmenprospekten oder Ergebnisberichten übereinstimmen. Schließlich sind wir ja alle Menschen und möchten mit unseren Parallelrechnerleistungen glänzen.