Mittwoch Apr 16, 2008

Benchmarken ist eine Kunst...

Ich mache jetzt 8 Jahre Benchmarks.  In dieser Zeit ist mir so das eine oder andere untergekommen, nicht zuletzt auch der eine oder andere Fall, in dem nicht das Testsystem, sondern der Lastgenerator gemessen wurde.  Soll ja vorkommen, und schliesslich machen die meisten Leute so etwas nicht regelmaessig.  Bis auf die Profis eben, die u.A. jeder Hardwarehersteller dafuer bezahlt, dass sie so Benchmarks wie z.B. den SPEC CPU2006 auf neuer Hardware solange tunen, bis ein optimaler, fuer den Hersteller natuerlich guenstiger Wert, dabei herauskommt.  Wobei natuerlich streng darauf geachtet wird, dass dieser Wert auch reproduzierbar ist - schliesslich will man sich ja auch seine Glaubwuerdigkeit nicht beschaedigen.

Jetzt lese ich neulich in einer renomierten deutschen IT-Zeitschrift davon, dass ein Redakteur versucht hat, eben diesen Benchmark, den SPEC CPU2006, auf einer T5220 nachzumessen.  Das ist nicht verkehrt, schliesslich ist Reproduzierbarkeit ein Ziel solcher Benchmarks.  Wie das bei aufwendigeren Benchmarks so ueblich ist, stiess auch dieser Redakteur auf gewisse Schwierigkeiten.  Die einzelnen Jobs dauerten lange - zu lange fuer die ihm zur Verfuegung stehende Zeit auf dem Testsystem.  Desweiteren konnte er mangels Hauptspeicher nicht die Maximalzahl der Jobs starten, die er fuer das Nachstellen der offiziellen Werte gebraucht haette.  Dass sein Testsystem nicht mit 1.4 GHz, sondern nur mit 1.2 GHz getaktet war, war da dann auch nicht mehr wesentlich.  

Weil also nur ein einzelner Job tatsaechlich durchlief (einer von 64), und weil der Hauptspeicher fuer 64 Jobs und die Zeit fuer die Jobs mit z.B. 16 oder 32 Threads fehlte, blieb dem Redakteur nichts anderes uebrig, als das Ergebnis seines Einzellaufs hochzurechnen.  Er war enttaeuscht, dass 100% Skalierung bei einem Messpunkt am unteren Ende nicht zu erreichen war.

Das alles ist nicht ungewoehnlich.  Zeit gibt es bei Benchmarks eigentlich nie ausreichend.  Und man darf kaum erwarten, dass ein erster Schuss mit einer doch eher grossen Benchmark-Suite wie dem SPEC CPU2006 gleich sitzt.  Enttaeuscht war ich jedoch von den Schlussfolgerungen:

Weil Sun die Werte mit 64GB Hauptspeicher gerechnet hat schliesst der Redakteur, dass die CPU nur mit diesem Speicherausbau die entsprechende Leistung bringt.  Ja, natuerlich braucht die Benchmarksuite 64GB RAM, wenn man 64 Threads davon testen will.  Aber wenn die tatsaechlich bei einem Kunden im Einsatz befindliche Anwendung fuer 64 Threads weniger Hauptspeicher benoetigt, hat es doch die selbe CPU zur Verfuegung, oder?

Weiter wird in Frage gestellt, ob denn 64GB RAM in "professionellen Umgebungen" ueblich sind.  Ist das nicht ganz stark davon abhaengig, welche Anwendung dieser Profi benoetigt?  Und die Leistungsfaehigkeit haengt ja, siehe oben, nicht vom RAM-Ausbau ab.  (Jedenfalls nicht erheblich - die Memory-Bandbreite ist durchaus von der Anzahl der DIMMs abhaengig, aber man kann ja auch 16 1GB DIMMs einbauen....)

Ich koennte jetzt noch weiter gehen und kleinere Unstimmigkeiten in diesem Artikel aufzaehlen.  Aber das fuehrt zu nichts.  Nur schade, dass es dem Redakteur nicht gelungen ist, nach dem einen SPEC CPU2006-Job und dem Nachschlagen von SPECjbb2005 noch weitere Benchmarks (wie z.B. Lotus Notes, SAP SD, SPECweb2005) zu betrachten, oder in einigen Blogs ( RWTH Aachen, Uni Erlangen) zu lesen, was an echtem Number-Crunching interessierte Forscher von der CPU halten.  Aber letztlich ist es eben doch eine Kunst, das Benchmarken.

About

Neuigkeiten, Tipps und Wissenswertes rund um SPARC, CMT, Performance und ihre Analyse sowie Erfahrungen mit Solaris auf dem Server und dem Laptop.

This is a bilingual blog (most of the time). Please select your prefered language:
.
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.

Search

Categories
Archives
« April 2014
MoDiMiDoFrSaSo
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Heute