Das Thema "Benchmarking" ist auf den ersten Blick ebenso simpel, wie bei genauerer Betrachtung kontrovers. Man nehme irgendeine Aufgabe, werfe sie verschiedenen Maschinen zum Fraß vor und messe wie lange sie dafür brauchen. Der mit der kürzesten Zeit oder dem höchsten Durchsatz gewinnt das kleine Rennen. So weit, so gut. Bei der Auswahl des Benchmark-Tools jedoch beginnt bereits die Schwierigkeit. Man schicke einen Audi Q7 und einen Porsche 911 auf eine Wettfahrt um die Nürburgring Nordschleife. Der Porsche gewinnt. Warum? Weil der Q7 nicht dafür gebaut wurde. Kann man daraus schließen, dass der Porsche aufgrund dieses "Benchmarks" das bessere Auto ist? Natürlich nicht! Der Porsche gewinnt hier, da er exakt für diese Aufgabe gebaut wurde und der Q7 nicht.
Das selbe Phänomen haben wir seit jeher im Computer-Bereich. Manche Disziplinen liegen dem einen System oder Prozessor besser, manche dem anderen. Das kann an der Art der Programmierung liegen, am Compiler oder an der Aufgabe an sich. Nehmen wir z.B. den integrierten Benchmark im Archiviertool WinRAR. Der Test ist extrem Latenz empfindlich. Ein AMD Phenom mit seinem integrierten Memory-Controller lässt einem Core 2 Quad hier keine Chance, selbst wenn er deutlich höher getaktet ist. Ein Fall von Vorteil durch die Aufgabe an sich. Oder das Tool SuperPI. Das Binary wurde 1995 (!) übersetzt. Damals wurde für 486er, bestenfalls für Pentium-Prozessoren compiliert. Der 486er hatte gar keine, der Pentium lediglich eine Fließkomma-Pipeline. AMD-Prozessoren sehen bei diesem Test verdammt alt aus, da K7, K8 und K10 hier keinerlei Nutzen aus ihren drei FPU-Pipelines mit relativ vielen Stufen und langer Latenz ziehen können. Ein Thema für die Abteilung "Codeoptimierung".
Letzteres ist das Dilemma beim benchmarken mit fertigen Binaries. Man weiß nie mit welchem Compiler und welchen Optimierungsflags der Quellcode übersetzt wurde. Aus diesem Grund ermöglicht die weltgrößte Benchmark-Organisation, die SPEC, ihren Teilnehmern aus dem gleichen Quellcode mit verschiedenen Parametern und freier Wahl an Compilern einen für ihren Schützling optimierten Code zu erzeugen. So ist ausgeschlossen, dass dem Prozessor die Optimierungen nicht schmecken. Ferner liegt der Quellcode vor und man kann sich davon überzeugen, dass der Code keinerlei künstliche Bremsen enthält, die das eigene Produkt benachteiligt.
Beim Testen mit fertigen Programmen, wie es im Consumer-Markt meistens der Fall ist, muss man sich auf die gängigen Praxisanwendungen (WinRAR, VirtualDub + DivX/XviD) oder auf synthetische Benchmarks (Sandra, PCMark, 3DMark) verlassen. Und hier geht es für die Hersteller um viel Geld. Wenn das Ergebnis eines häufig benutzten 3DMarks beispielsweise sagt, dass eine Radeon 4850 doppelt so schnell wäre, wie eine GeForce 280, dann ist das wie ein Lottogewinn für das Unternehmen. So gab es bereits vor etlichen Jahren Streitigkeiten wegen unerlaubter (oder auch nicht?) Optimierungen für den 3DMark03, um im direkten Konkurrrenzkampf besser dazustehen, Optimierungen, die nur in diesem Benchmark greifen und dem Anwender keinerlei Nutzen für echte Spiele brachten.
Im aktuellen Fall jedoch geht es nicht um Optimierungen für den 3DMark von Futuremark, sondern um den PCMark der selben Firma an sich, der sich zum Ziel gesetzt hat die Gesamtleistung eines Systems zu ermitteln. Vor ein paar Tagen jedoch hat Arstechnica einen hochinteressanten Artikel veröffentlicht, der die Glaubwürdigkeit des in der Consumer- und Enthusiasten-Welt allseits beliebten PCMark2005 doch arg unterminiert.
Ausgangspunkt für den Test war ein Vergleich zwischen dem Intel Atom und dem VIA Nano Prozessor, beides CPUs für den UMPC-Markt, den der Intel Atom gewann. Allerdings haben die Tester von Arstechnica ihren Testkandidaten etwas genauer auf den Zahn gefühlt und zwar auf eine äußerst clevere Art und Weise. Die Tester schnappten sich das VIA Nano System und gaukelten dem PCMark2005 über Manipulationen an der Vendor CPUID des VIA-Prozessors vor, es handle sich nicht um einen VIA, sondern um einen Intel Prozessor. Und was geschah? Obwohl es sich um den selben Prozessor handelte (lediglich mit der CPUID eines Intel versehen), stieg der Wert des Memory-Benchmarks von 1845 auf satte 2721 und lag damit plötzlich vor dem Intel Atom, der lediglich einen Wert von 2428 erreichte.
Normalerweise prüfen Programme beim Start die Features eines Prozessors. "Kann er MMX, 3DNow!, SSE, SSE2, SSE3?", etc. und aktivieren oder deaktivieren daraufhin die ein oder andere Optimierung - was ganz normal ist, da das Programm sofort abstürzen würde, wenn es einem Prozessor, der nur SSE unterstützt, SSE3-Befehle vorsetzen würde. Legitim wäre auch noch die CPU-Familie abzufragen. Ein Pentium 4 benötigt aufgrund seiner Netburst-Architektur mit langer Pipeline und kleinen Caches andere Optimierungen, als ein Core 2 mit mittellangen Pipelines und riesigen Caches. Aber wie kann allein die Änderung der Hersteller-ID derartige Unterschiede bewirken? Aus Interesse änderten die Tester die Vendor-CPUID auch noch auf AuthenticAMD. Hier ergaben sich auch leichte Vorteile gegenüber der VIA Original-ID, mit einem Wert von 2012 jedoch deutlich niedrigere.
Nun könnte man argumentieren, dass Futuremark im Jahr 2005, als der PCMark2005 entwickelt wurde, den nagelneuen VIA Nano noch nicht auf der Liste haben und daher nicht wissen konnte, dass VIA-Prozessoren irgendwann einmal SSE, SSE2 und SSE3 unterstützen würden, was für den Memory-Test durchaus relevant ist. Aber woher stammt der Unterschied zwischen der Vendor-ID AuthenticAMD und GenuineIntel? Die AMD-Prozessoren unterstützten SSE und SSE2 bereits seit 2003, SSE3 kam 2005 dazu. Also wieso sinkt der Durchsatz trotzdem von 2721 auf 2012 auf dem selben (VIA-)Prozessor, sobald man dem PCMark2005 einen AMD- statt eines Intel-Prozessors vorgaukelt?
Bereits seit geraumer Zeit gibt es heftige Diskussionen über die Binaries des Intel-Compilers. Hier ist es bei einigen Versionen ähnlich. Sobald man dem Programm vorgaukelt, es liefe nicht mehr auf einem Intel-, sondern auf einem AMD-Prozessor - unabhängig von den unterstützten Befehlssätzen und Features - sinkt die Performance teils empfindlich. Hier könnte man jedoch noch argumentieren, dass der Intel-Compiler von Intel entwickelt und finanziert wurde und Intel alles Recht der Welt hat dafür zu sorgen (selbst künstlich), dass die hauseigenen Prozessoren besser damit laufen, als die des Konkurrenten. Natürlich gibt es auch dazu andere Meinungen und hier eine Diskussion dazu. Wieso jedoch der PCMark2005, der nicht von Intel, sondern von Futuremark entwickelt wurde, einer Firma, die nach eigener Aussage auf maximale Neutralität bedacht ist, in dieser Weise auf die Vendor-IDs reagiert, das kann wohl nur Futuremark selbst beantworten...
Diesen Artikel bookmarken oder senden an ...
