News Herstellerspezifische Code-Optimierungen in Benchmarks und deren Nachweis
- Ersteller miriquidi
- Erstellt am
User-News
Von miriquidi
Hinweis: Diese "User-News" wurde nicht von der Planet 3DNow! Redaktion veröffentlicht, sondern vom oben genannten Leser, der persönlich für den hier veröffentlichten Inhalt haftet.1 Einleitung
CPU-Benchmarks dienen zur Messung der Rechengeschwindkeit von typischen Hauptprozessoren in z.B. Notebooks oder Desktop-PCs. Sie sind ein essentielles Mittel zur Bewertung von neuer Hardware in der Fachpresse (c't, Chip, ...) und in großen Internetmagazinen. Ihre Ergebnisse entscheiden über Kaufempfehlungen und Testsieger.
Doch wie vertrauenswürdig sind diese Messmittel? Ein nicht verstummendes Gerücht in der Internet-Hardwaregemeinde lautet, dass gewisse Prozessorbenchmarks die vergebenen Punktwertungen je nach Hersteller bewusst manipulieren. Erstmalig wurde dies 2008 von ArsTechnica mittels eines Via Nano-Systems beim Benchmark PCMark 2005 nachgewiesen [ArsTechnica]. Dieser Artikel stellt einen alternativen, softwarebasierten Ansatz vor, um unabhängig von exotischer Hardware Benchmarks überprüfen zu können.
Hintergrund des Manipulationsverdachtes ist die mutmaßliche Existenz verschiedener Codepfade in einem Programm, welche unterschiedliche Befehlsfolgen enthalten, die zum gleichen Ergebnis führen. Dies ist legitim, sofern schnellere bzw. besser optimierte Codepfade auf spezielle Befehlssätze wie SSE oder AVX angewiesen sind und Prozessoren ohne diese Befehle einen langsameren Codepfad nutzen. Illegitim wäre es, wenn der optimierte Codepfad nur für CPUs eines Herstellers zugänglich wäre, also z.B. vom Vorhandensein einer bestimmten Herstellerbezeichnung abhängt.
Die Gerüchteküche brodelt speziell um die Standardbenchmarks der Cinebench-Reihe, welche unter Mitwirkung eines Intel-Compilers entstanden sind. Für die Meinungsbildung im Internet sind dabei leider wissenschaftliche Grundsätze wie stichhaltige Beweisführung scheinbar recht belanglos, so dass sich anscheinend noch niemand die Mühe machte, der Sache auf den Grund zu gehen. Dieser Artikel soll diese Lücke anhand des Beispiels Cinebench R10 (32-Bit) schließen. Die dafür genutzte Methode eignet sich prinzipiell jedoch auch zur Überprüfung anderer Benchmarks. Cinebench R10 entstammt dem Jahr 2007 als noch Core 2 Duos und K8s die High-End-PCs befeuerten und erste Quad-Core Prozessoren erschienen. Es war damals ein in der Fachpresse häufig genutztes Messmittel, da es gut mit mehreren Kernen skaliert und die Mehrleistung der damals brandneuen Vierkern-Prozessoren mit vielen Punkten würdigte.
Für die Untersuchung waren vier Software-Werkzeuge erforderlich:
2 Maschinencodemanipulation
2.1 Identifikation verdächtigen Maschinencodes
Die Datei „Cinebench R10.exe“ enthält x86 Maschinencode, welcher direkt auf dem Hauptprozessor ausgeführt wird. Sofern verdächtige Stellen darin auftauchen, haben diese mit dem x86 Maschinenbefehl „0FA2h“ (? das kleine h am Ende steht für die Kennzeichnung der Zeichenfolge davor als Hexadezimalzahl). Bekannter ist dessen Assembler-Repräsentation „cpuid“. Der Befehl samt Eingangsparameter und Ausgabewerten wird in [cpuid] erklärt. Skizzenhaft beschrieben, betrachtet „cpuid“ das Prozessorregister eax, und befüllt, je nach in eax stehender Bitfolge, anschließend die Register eax, ebx, ecx und edx mit Informationen über den Prozessor. Das können Informationen über den Hersteller, zur Cache-Organisation oder zu unterstützten Befehlssätzen sein.
Um verdächtige Stellen zu finden, öffnet man mit dem Borg Disassembler die exe-Datei unter Verwendung des Befehlssatzes „Pentium II with KNI“. Borg analysiert anschließend den Code und stellt ihn im Schema von Codebeispiel 1 dar. In der linken Spalte steht die hexadezimale Adresse („Stelle“) des Maschinencodes (mit dem Vorsatz „1000:“ und ohne h am Ende) in der exe-Datei. Dahinter der Maschinencode in Hexadezimalschreibweise (z.B. „55“, auch ohne h am Ende) und am Ende die Übersetzung in Assembler-Code (z.B. „push ebp“).
Codebeispiel 1:
Dieses Analyseergebnis speichert man als Text („Save as Text“) in eine Textdatei, öffnet diese mit Notepad++ und sucht die Zeichenfolge „cpuid“. In der deassemblierten „Cinebench R10.exe“ taucht der Befehl 17mal auf. Beispielhaft ist eine Stelle daraus in Codebeispiel 2 weiter unten aufgeführt.
Codebeispiel 2:
An der Stelle 00ba6339h wird „cpuid“ aufgerufen. Für den Eingangsparameter des cpuid-Befehls ist die Zeile davor mit dem Befehl „xor eax, eax“ wichtig. Dort wird bitweise die xor-Verknüpfung des Registers eax mit sich selbst vorgenommen. Bei xor ergeben 0 und 0 sowie 1 und 1 jeweils 0, 0 und 1 sowie 1 und 0 ergeben jeweils 1 [XOR]. Folglich ergibt die Verknüpfung einer Zahl mit sich selbst für alle Bits null, was im Zielregister eax hinterlegt wird. Der cpuid-Befehl in der nächsten Stelle 00ba6339h wird also mit dem Operanden 00000000h (? hexadezimal) im Register eax ausgeführt und legt gemäß [cpuid] in den Registern ebx, ecx und edx den sogenannten „Vendor-ID-String“ ab, welcher den CPU-Hersteller identifiziert.
2.2 Manipulation des Maschinencodes
Hinter der Stelle 00ba6339h folgen vier Zeilen, in welchen die cpuid-Werte per mov aus den Registern in den Arbeitsspeicher geschrieben werden. Zum Nachweis von herstellerspezifischer Codepfaden kann nun die betreffende Stelle im Maschinencode des Programms manipuliert werden. Hierzu werfen wir einen Blick auf die drei Stellen 00ba633eh, 00ba6341h und 00ba6344h in Codebeispiel 3, welche aus Codebeispiel 2 entstammen:
Codebeispiel 3:
Der Inhalt des Registers ebx wird an die Stelle [ebp-08h] kopiert, ecx an die Stelle [epb-14h] und edx an die Stelle [ebp-10h]. ebp ist ein Pointer im Prozessor, aus welchen nach Subtraktion der nachfolgenden Hexadezimalzahl die Zieladresse im Arbeitsspeicher errechnet wird. Im Arbeitsspeicher hat man dann bei einem Intel-Prozessor den String „GenuineIntel“, bei einem AMD-Prozessor „AuthenticAMD“ und bei einem Via Prozessor „CentaurHauls“ stehen.
Zur Ausschaltung der CPU-Erkennung werden nun die Zieladressen der mov-Befehle zyklisch vertauscht. ebx soll an die Stelle [ebp-10h], ecx an die Stelle [ebp-08h] und edx an die Stelle [ebp-14h] kopiert werden. Mittels des Online-Assembler-Tools [OnlineAssembler] kann nachgeprüft werden, dass hierzu nur die letzten zwei Hexadezimalzahlen der jeweiligen Maschinenbefehle vertauscht werden müssen. Aus den Maschinenbefehlen „895df8“, „894dec“ und „8955f0“ wird durch die Modifikation „895df0“, „894df8“ und „8955ec“.
Geändert wird der Maschinencode mit dem Hex-Editors HxD. Die zu bearbeitende Stelle im Hex-Editor ergibt sich aus der Zeilennummer von Borg (00ba633eh), im Fall von Cinebench R10.exe vermindert um einen Offset von 0040000h. Abb. 1 zeigt die Datei vor und nach der Modifikation. Anstatt „GenuineIntel“ legt das manipulierte Programm den String „ntelineIGenu“ als Herstellerbezeichnung in den Arbeitsspeicher ab. Bei einem AMD-Prozessor wäre es statt „AuthenticAMD“ nun „ enticAMDAuth“. Das ganze kann man als „Vendor-ID-Mod“ bezeichnen.
Abbildung 1: Der Maschinencode in Cinebench R10.exe vor und nach der Modifikation
Diese Änderungen pflegt man für die Datei „Cinebench R10.exe“ sowie die Datei „advancedrender.cdl“ ein, welche einen identischen Maschinencode-Abschnitt an der Stelle 6bad3h enthält. Es gibt darüber hinaus noch weitere *.cdl-Dateien mit diesem Codeabschnitt, deren Einfluss auf den Punktwert ist jedoch extrem gering. Ich habe diese getestet, letztendlich dann aber für die Messung nicht mit verwendet.
Neben der in Codebeispiel 1 gezeigten Stelle finden sich weitere cpuid-Befehle in der deassemblierten "Cinebench R10.exe", welche teilweise mit anderen eax-Argumenten aufgerufen werden. Auch um diese wurde der Maschinencode verändert, es zeigten sich dabei jedoch nur bei den zwei in Codebeispiel 2 enthaltenen Stellen signifikante Änderungen am Benchmark Ergebnis. Dies bedeutet im Endeffekt, dass der Nachweis von herstellerspezifischen Optimierungen sprichwörtlich eine Suche der Nadel im Heuhaufen ist.
3 Messergebnisse
Abschließend vergleicht man die Messergebnisse des Programms im Originalzustand mit jenen des Programms nach Modifikation von „Cinebench R10.exe“ und „advancedrenderer.cdl“. Hierfür standen die in Tab. 1 verwendeten Systeme zur Verfügung. Das Durchprobieren, ob einzelne cpuid-Aufrufe einen Einfluss auf den Punktwert haben, wurde ausschließlich auf dem Core-i7-2640M durchgeführt.
Tabelle 1: Übersicht der zur Überprüfung des Mods verwendeten Systeme
* - Turbo wurde deaktiviert
Aus Gründen der Reproduzierbarkeit wurde nur der Single-Threaded Modus von Cinebench R10 genutzt, da eine andere Rechengeschwindigkeit in Teilen des Bildes die Programmentscheidung zum Start eines neuen Threads beeinflussen könnte. Jede Messung wurde zehnmal wiederholt um eine statistisch valide Schätzung der Messgenauigkeit zu erhalten.
Tab. 2 enthält die Messergebnisse der einzelnen Prozessoren. Die Punktwertänderung beim AMD K8 und der AMD K10 durch den Vendor-ID-Mod liegen jeweils unterhalb der Messunsicherheit und ist somit nicht nachweisbar. Weniger eindeutig ist der Einfluss des Vendor-ID-Mods beim Pentium-III basierten Celeron 1300 MHz. Dieser wird etwas höher bewertet, sofern er aus Programmsicht kein Intel-Prozessor ist, wobei die Veränderung die Messunsicherheit kaum übersteigt. Signifikant (d.h. deutlich größer als die Messunsicherheit) verschlechtert sich das Punktergebnis hingegen bei allen anderen Intel-Prozessoren. Beim Core-2-Quad, Intel Atom, Sandy Bridge und Pentium M sind es ca. um die 3 %, beim Pentium IV hingegen sogar über 4,5 %.
Tabelle 2: Cinebench R10 32 Bit Single Punktbewertung sowie deren Veränderung durch den Vendor-ID-Mod.
Aus den Messwerten kann man schließen, dass es keinen Codepfad gibt, der spezifisch nur für AMD-Prozessoren mit der Bezeichnung „AuthenticAMD“ verwendet wird / optimiert ist. Dies ist unabhängig davon, ob die Architektur zum Veröffentlichungszeitpunkt des Benchmarks (2007) schon länger bekannt war ( K8 ) oder nicht ( K10 ). Hingegen scheint Cinebench R10 mindestens für Teile der getesteten Rechnung einen anderen Codepfad speziell für Intel-Prozessoren zu verwenden. Ob für alle Architekturen der gleiche Pfad benutzt wird, ist aufgrund der Beschränkungen der Analysemethode nicht nachvollziehbar.
Nichts destotrotz bedeutet dies, dass ein und derselbe Prozessor anders (i.d.R. schlechter) bewertet wird, wenn er aus Programmsicht nicht die Intel-Vendor-ID-Bezeichnung „GenuineIntel“ trägt. Dies legt den Schluss nah, dass besonders optimierte Codepfade nur von CPUs eines Herstellers genutzt werden dürfen, was zumindest den Verdacht der Manipulation aufkeimen lässt. Völlig unklar ist dabei jedoch, ob der Codepfad mutwillig eingebaut wurde oder vom wem er eingebaut wurde. Kein normaler Softwareentwicklern liest nach dem Kompilieren den von ihm erzeugten Maschinencode per Hand und überprüft ihn. Ebenso wissen wir nicht, ob eine AMD oder VIA CPU von der Nutzung eines alternativen Codepfads überhaupt profitieren oder sich wie der Pentium III verhalten würde.
Auf quantitativer Sicht ist festzuhalten, dass der aufgedeckte Grad der Messwertverfälschung mit maximal 4,5 % und meist nur ca. 3 % recht gering ist. Bei Verwendung verschiedener Betriebssystemkonfigurationen und Hintergrundprogramme liegt er fast schon im Bereich der Messgenauigkeit. Da Cinebench R10 jedoch explizit als Messprogramm für Prozessoren erschien, sollten systematische, herstellerabhängige Messabweichungen möglichst komplett ausgeschlossen sein.
Neben der Rechengeschwindigkeit ist auch die Frage relevant, ob beide Codepfade das gleiche Ergebnis, d.h. das gleiche Ausgabebild, produzieren. Diese Frage kann nicht beantwortet werden, da bereits die Ausgabe verschiedener Durchläuf mit einem Programmzustand voneinander abweicht. Um dies nachzuweisen, fertigt man eine Bildschirmkopie des Ausgabebildes auf, fügt es z.B. in GIMP ein und legt die Bildschirmkopie eines zweiten Durchlaufs darüber. Man erkennt dann, dass z.B. im Bereich direkt unter dem gerenderten Motorrad beide Bilder ein unterschiedliches Rauschen zeigen. Die Differenz zwischen beiden Codepfaden ist kleiner als dieses Rauschen und somit nicht nachweisbar.
4 Schlussfolgerungen und Quellen
Generell eröffnen sich aus den Ergebnissen zwei grundlegende Fragen hinsichtlich der „Fairness“ von CPU-Benchmarks:
a) Sind Benchmark-Ergebnisse vergleichbar, wenn sie je nach Prozessor unterschiedliche Maschinenbefehle für den gleichen Algorithmus verwenden?
Darüber kann man unterschiedlicher Meinung sein. Ich persönlich tendiere zu einem „ja“ um die evolutionäre Weiterentwicklung des Befehlssatzes von Prozessoren abzubilden. Man müsste dann diese Optimierung aber auch für alle Prozessorhersteller freigeben, was zur zweiten Fragen führt.
b) Welcher Grad von Transparenz ist für die Wahl der Codepfade bzw. des genutzten Befehlssatzes (SSE, AVX, …) bei einer bestimmten CPU nötig?
Der auf einem Prozessor genutzte Befehlssatz für das Programm (und die vielen, vielen Unterfunktionen) liegt in den Händen des Compilers und ist vom Programmierer auf Ebene seiner Hochsprache (z.B. C++) nicht einzusehen. Insofern dürfte es schwierig sein, dort verlässliche Angaben zu machen, da kein Programmierer den erzeugten Maschinencode per Hand liest. Ohne ein passendes Analysewerkzeug zur Überprüfung des gesamten Codes ist dies nicht zu stemmen, da viel zu aufwändig. Das Manipulieren von ein paar Zieladressen um einen extrem seltenen cpuid-Befehl ist dann eben doch etwas anderes.
Insofern bleibt aus meiner Sicht nur der Test von fertigen Benchmarks hinsichtlich herstellerspezifischer Optimierungen. Der dargelegte Weg ist manuell durchgeführt zu aufwändig, so dass er automatisiert werden müsste. Weiterhin ist auch festzuhalten, dass böswillige Manipulationen sich damit nicht aufdecken lassen. Maschinencode kann z.B. erst zur Laufzeit entschlüsselt und dann ausgeführt werden.
Im speziellen Fall von Cinebench R10 ist die Bewertung der Ergebnisse zudem hinsichtlich der Anwendungsrelevanz des Benchmarks komplizierter: Für Ersteller computeranimierter Filme sind die Stromkosten der Rendermaschinen ein wesentlicher Kostenfaktor. Zur Kostenminimierung wird dann natürlich der bestmögliche Kompiler eingesetzt, welcher von Intel stammt. Wenn sich dessen Kompilate immer so verhalten wie Cinebench R10, misst es für diesen speziellen Anwendungsfall Rendering richtig.
Die meisten Anwendugsprogramme für Windows werden jedoch immer noch mit Microsoft-Compilern erstellt. Somit ist die vom Cinebench Hersteller Maxon propagierte Anwendungsrelevanz des Benchmarks doch überzogen dargestellt [golem]:
Quellen
[ArsTechnica] – http://arstechnica.com/gadgets/2008/07/atom-nano-review/6/
[OnlineAssembler] – https://defuse.ca/online-x86-assembler.htm
[cpuid] – http://www.lowlevel.eu/wiki/CPUID
[XOR] – http://andremueller.gmxhome.de/befehle.html
[golem] - http://www.golem.de/0708/54002.html
CPU-Benchmarks dienen zur Messung der Rechengeschwindkeit von typischen Hauptprozessoren in z.B. Notebooks oder Desktop-PCs. Sie sind ein essentielles Mittel zur Bewertung von neuer Hardware in der Fachpresse (c't, Chip, ...) und in großen Internetmagazinen. Ihre Ergebnisse entscheiden über Kaufempfehlungen und Testsieger.
Doch wie vertrauenswürdig sind diese Messmittel? Ein nicht verstummendes Gerücht in der Internet-Hardwaregemeinde lautet, dass gewisse Prozessorbenchmarks die vergebenen Punktwertungen je nach Hersteller bewusst manipulieren. Erstmalig wurde dies 2008 von ArsTechnica mittels eines Via Nano-Systems beim Benchmark PCMark 2005 nachgewiesen [ArsTechnica]. Dieser Artikel stellt einen alternativen, softwarebasierten Ansatz vor, um unabhängig von exotischer Hardware Benchmarks überprüfen zu können.
Hintergrund des Manipulationsverdachtes ist die mutmaßliche Existenz verschiedener Codepfade in einem Programm, welche unterschiedliche Befehlsfolgen enthalten, die zum gleichen Ergebnis führen. Dies ist legitim, sofern schnellere bzw. besser optimierte Codepfade auf spezielle Befehlssätze wie SSE oder AVX angewiesen sind und Prozessoren ohne diese Befehle einen langsameren Codepfad nutzen. Illegitim wäre es, wenn der optimierte Codepfad nur für CPUs eines Herstellers zugänglich wäre, also z.B. vom Vorhandensein einer bestimmten Herstellerbezeichnung abhängt.
Die Gerüchteküche brodelt speziell um die Standardbenchmarks der Cinebench-Reihe, welche unter Mitwirkung eines Intel-Compilers entstanden sind. Für die Meinungsbildung im Internet sind dabei leider wissenschaftliche Grundsätze wie stichhaltige Beweisführung scheinbar recht belanglos, so dass sich anscheinend noch niemand die Mühe machte, der Sache auf den Grund zu gehen. Dieser Artikel soll diese Lücke anhand des Beispiels Cinebench R10 (32-Bit) schließen. Die dafür genutzte Methode eignet sich prinzipiell jedoch auch zur Überprüfung anderer Benchmarks. Cinebench R10 entstammt dem Jahr 2007 als noch Core 2 Duos und K8s die High-End-PCs befeuerten und erste Quad-Core Prozessoren erschienen. Es war damals ein in der Fachpresse häufig genutztes Messmittel, da es gut mit mehreren Kernen skaliert und die Mehrleistung der damals brandneuen Vierkern-Prozessoren mit vielen Punkten würdigte.
Für die Untersuchung waren vier Software-Werkzeuge erforderlich:
- Borg Disassembler in der Version 2.28 von Chronos
- Notepad++
- HxD in der Version 1.7.7.0 als Hex-Editor
- Online-Assembler [OnlineAssembler]
2 Maschinencodemanipulation
2.1 Identifikation verdächtigen Maschinencodes
Die Datei „Cinebench R10.exe“ enthält x86 Maschinencode, welcher direkt auf dem Hauptprozessor ausgeführt wird. Sofern verdächtige Stellen darin auftauchen, haben diese mit dem x86 Maschinenbefehl „0FA2h“ (? das kleine h am Ende steht für die Kennzeichnung der Zeichenfolge davor als Hexadezimalzahl). Bekannter ist dessen Assembler-Repräsentation „cpuid“. Der Befehl samt Eingangsparameter und Ausgabewerten wird in [cpuid] erklärt. Skizzenhaft beschrieben, betrachtet „cpuid“ das Prozessorregister eax, und befüllt, je nach in eax stehender Bitfolge, anschließend die Register eax, ebx, ecx und edx mit Informationen über den Prozessor. Das können Informationen über den Hersteller, zur Cache-Organisation oder zu unterstützten Befehlssätzen sein.
Um verdächtige Stellen zu finden, öffnet man mit dem Borg Disassembler die exe-Datei unter Verwendung des Befehlssatzes „Pentium II with KNI“. Borg analysiert anschließend den Code und stellt ihn im Schema von Codebeispiel 1 dar. In der linken Spalte steht die hexadezimale Adresse („Stelle“) des Maschinencodes (mit dem Vorsatz „1000:“ und ohne h am Ende) in der exe-Datei. Dahinter der Maschinencode in Hexadezimalschreibweise (z.B. „55“, auch ohne h am Ende) und am Ende die Übersetzung in Assembler-Code (z.B. „push ebp“).
Codebeispiel 1:
Code:
...
1000:00401000 55 push ebp
1000:00401001 8bec mov ebp, esp
1000:00401003 33c0 xor eax, eax
1000:00401005 8be5 mov esp, ebp
1000:00401007 5d pop ebp
…Dieses Analyseergebnis speichert man als Text („Save as Text“) in eine Textdatei, öffnet diese mit Notepad++ und sucht die Zeichenfolge „cpuid“. In der deassemblierten „Cinebench R10.exe“ taucht der Befehl 17mal auf. Beispielhaft ist eine Stelle daraus in Codebeispiel 2 weiter unten aufgeführt.
Codebeispiel 2:
Code:
…
1000:00ba6335 51 push ecx
1000:00ba6336 9d popfd
1000:00ba6337 33c0 xor eax, eax
1000:00ba6339 0fa2 cpuid
1000:00ba633b 8945fc mov [ebp-04h], eax
1000:00ba633e 895df8 mov [ebp-08h], ebx
1000:00ba6341 894dec mov [ebp-14h], ecx
1000:00ba6344 8955f0 mov [ebp-10h], edx
1000:00ba6347 b801000000 mov eax, 01h
1000:00ba634c 0fa2 cpuid
1000:00ba634e 8945e8 mov [ebp-18h], eax
1000:00ba6351 895df4 mov [ebp-0ch], ebx
1000:00ba6354 894de0 mov [ebp-20h], ecx
1000:00ba6357 8955e4 mov [ebp-1ch], edx
1000:00ba635a e91a000000 jmp loc_00ba6379
…An der Stelle 00ba6339h wird „cpuid“ aufgerufen. Für den Eingangsparameter des cpuid-Befehls ist die Zeile davor mit dem Befehl „xor eax, eax“ wichtig. Dort wird bitweise die xor-Verknüpfung des Registers eax mit sich selbst vorgenommen. Bei xor ergeben 0 und 0 sowie 1 und 1 jeweils 0, 0 und 1 sowie 1 und 0 ergeben jeweils 1 [XOR]. Folglich ergibt die Verknüpfung einer Zahl mit sich selbst für alle Bits null, was im Zielregister eax hinterlegt wird. Der cpuid-Befehl in der nächsten Stelle 00ba6339h wird also mit dem Operanden 00000000h (? hexadezimal) im Register eax ausgeführt und legt gemäß [cpuid] in den Registern ebx, ecx und edx den sogenannten „Vendor-ID-String“ ab, welcher den CPU-Hersteller identifiziert.
2.2 Manipulation des Maschinencodes
Hinter der Stelle 00ba6339h folgen vier Zeilen, in welchen die cpuid-Werte per mov aus den Registern in den Arbeitsspeicher geschrieben werden. Zum Nachweis von herstellerspezifischer Codepfaden kann nun die betreffende Stelle im Maschinencode des Programms manipuliert werden. Hierzu werfen wir einen Blick auf die drei Stellen 00ba633eh, 00ba6341h und 00ba6344h in Codebeispiel 3, welche aus Codebeispiel 2 entstammen:
Codebeispiel 3:
Code:
...
1000:00ba633e 895df8 mov [ebp-08h], ebx
1000:00ba6341 894dec mov [ebp-14h], ecx
1000:00ba6344 8955f0 mov [ebp-10h], edxDer Inhalt des Registers ebx wird an die Stelle [ebp-08h] kopiert, ecx an die Stelle [epb-14h] und edx an die Stelle [ebp-10h]. ebp ist ein Pointer im Prozessor, aus welchen nach Subtraktion der nachfolgenden Hexadezimalzahl die Zieladresse im Arbeitsspeicher errechnet wird. Im Arbeitsspeicher hat man dann bei einem Intel-Prozessor den String „GenuineIntel“, bei einem AMD-Prozessor „AuthenticAMD“ und bei einem Via Prozessor „CentaurHauls“ stehen.
Zur Ausschaltung der CPU-Erkennung werden nun die Zieladressen der mov-Befehle zyklisch vertauscht. ebx soll an die Stelle [ebp-10h], ecx an die Stelle [ebp-08h] und edx an die Stelle [ebp-14h] kopiert werden. Mittels des Online-Assembler-Tools [OnlineAssembler] kann nachgeprüft werden, dass hierzu nur die letzten zwei Hexadezimalzahlen der jeweiligen Maschinenbefehle vertauscht werden müssen. Aus den Maschinenbefehlen „895df8“, „894dec“ und „8955f0“ wird durch die Modifikation „895df0“, „894df8“ und „8955ec“.
Geändert wird der Maschinencode mit dem Hex-Editors HxD. Die zu bearbeitende Stelle im Hex-Editor ergibt sich aus der Zeilennummer von Borg (00ba633eh), im Fall von Cinebench R10.exe vermindert um einen Offset von 0040000h. Abb. 1 zeigt die Datei vor und nach der Modifikation. Anstatt „GenuineIntel“ legt das manipulierte Programm den String „ntelineIGenu“ als Herstellerbezeichnung in den Arbeitsspeicher ab. Bei einem AMD-Prozessor wäre es statt „AuthenticAMD“ nun „ enticAMDAuth“. Das ganze kann man als „Vendor-ID-Mod“ bezeichnen.
Abbildung 1: Der Maschinencode in Cinebench R10.exe vor und nach der Modifikation
Diese Änderungen pflegt man für die Datei „Cinebench R10.exe“ sowie die Datei „advancedrender.cdl“ ein, welche einen identischen Maschinencode-Abschnitt an der Stelle 6bad3h enthält. Es gibt darüber hinaus noch weitere *.cdl-Dateien mit diesem Codeabschnitt, deren Einfluss auf den Punktwert ist jedoch extrem gering. Ich habe diese getestet, letztendlich dann aber für die Messung nicht mit verwendet.
Neben der in Codebeispiel 1 gezeigten Stelle finden sich weitere cpuid-Befehle in der deassemblierten "Cinebench R10.exe", welche teilweise mit anderen eax-Argumenten aufgerufen werden. Auch um diese wurde der Maschinencode verändert, es zeigten sich dabei jedoch nur bei den zwei in Codebeispiel 2 enthaltenen Stellen signifikante Änderungen am Benchmark Ergebnis. Dies bedeutet im Endeffekt, dass der Nachweis von herstellerspezifischen Optimierungen sprichwörtlich eine Suche der Nadel im Heuhaufen ist.
3 Messergebnisse
Abschließend vergleicht man die Messergebnisse des Programms im Originalzustand mit jenen des Programms nach Modifikation von „Cinebench R10.exe“ und „advancedrenderer.cdl“. Hierfür standen die in Tab. 1 verwendeten Systeme zur Verfügung. Das Durchprobieren, ob einzelne cpuid-Aufrufe einen Einfluss auf den Punktwert haben, wurde ausschließlich auf dem Core-i7-2640M durchgeführt.
Tabelle 1: Übersicht der zur Überprüfung des Mods verwendeten Systeme
* - Turbo wurde deaktiviert
Aus Gründen der Reproduzierbarkeit wurde nur der Single-Threaded Modus von Cinebench R10 genutzt, da eine andere Rechengeschwindigkeit in Teilen des Bildes die Programmentscheidung zum Start eines neuen Threads beeinflussen könnte. Jede Messung wurde zehnmal wiederholt um eine statistisch valide Schätzung der Messgenauigkeit zu erhalten.
Tab. 2 enthält die Messergebnisse der einzelnen Prozessoren. Die Punktwertänderung beim AMD K8 und der AMD K10 durch den Vendor-ID-Mod liegen jeweils unterhalb der Messunsicherheit und ist somit nicht nachweisbar. Weniger eindeutig ist der Einfluss des Vendor-ID-Mods beim Pentium-III basierten Celeron 1300 MHz. Dieser wird etwas höher bewertet, sofern er aus Programmsicht kein Intel-Prozessor ist, wobei die Veränderung die Messunsicherheit kaum übersteigt. Signifikant (d.h. deutlich größer als die Messunsicherheit) verschlechtert sich das Punktergebnis hingegen bei allen anderen Intel-Prozessoren. Beim Core-2-Quad, Intel Atom, Sandy Bridge und Pentium M sind es ca. um die 3 %, beim Pentium IV hingegen sogar über 4,5 %.
Tabelle 2: Cinebench R10 32 Bit Single Punktbewertung sowie deren Veränderung durch den Vendor-ID-Mod.
Aus den Messwerten kann man schließen, dass es keinen Codepfad gibt, der spezifisch nur für AMD-Prozessoren mit der Bezeichnung „AuthenticAMD“ verwendet wird / optimiert ist. Dies ist unabhängig davon, ob die Architektur zum Veröffentlichungszeitpunkt des Benchmarks (2007) schon länger bekannt war ( K8 ) oder nicht ( K10 ). Hingegen scheint Cinebench R10 mindestens für Teile der getesteten Rechnung einen anderen Codepfad speziell für Intel-Prozessoren zu verwenden. Ob für alle Architekturen der gleiche Pfad benutzt wird, ist aufgrund der Beschränkungen der Analysemethode nicht nachvollziehbar.
Nichts destotrotz bedeutet dies, dass ein und derselbe Prozessor anders (i.d.R. schlechter) bewertet wird, wenn er aus Programmsicht nicht die Intel-Vendor-ID-Bezeichnung „GenuineIntel“ trägt. Dies legt den Schluss nah, dass besonders optimierte Codepfade nur von CPUs eines Herstellers genutzt werden dürfen, was zumindest den Verdacht der Manipulation aufkeimen lässt. Völlig unklar ist dabei jedoch, ob der Codepfad mutwillig eingebaut wurde oder vom wem er eingebaut wurde. Kein normaler Softwareentwicklern liest nach dem Kompilieren den von ihm erzeugten Maschinencode per Hand und überprüft ihn. Ebenso wissen wir nicht, ob eine AMD oder VIA CPU von der Nutzung eines alternativen Codepfads überhaupt profitieren oder sich wie der Pentium III verhalten würde.
Auf quantitativer Sicht ist festzuhalten, dass der aufgedeckte Grad der Messwertverfälschung mit maximal 4,5 % und meist nur ca. 3 % recht gering ist. Bei Verwendung verschiedener Betriebssystemkonfigurationen und Hintergrundprogramme liegt er fast schon im Bereich der Messgenauigkeit. Da Cinebench R10 jedoch explizit als Messprogramm für Prozessoren erschien, sollten systematische, herstellerabhängige Messabweichungen möglichst komplett ausgeschlossen sein.
Neben der Rechengeschwindigkeit ist auch die Frage relevant, ob beide Codepfade das gleiche Ergebnis, d.h. das gleiche Ausgabebild, produzieren. Diese Frage kann nicht beantwortet werden, da bereits die Ausgabe verschiedener Durchläuf mit einem Programmzustand voneinander abweicht. Um dies nachzuweisen, fertigt man eine Bildschirmkopie des Ausgabebildes auf, fügt es z.B. in GIMP ein und legt die Bildschirmkopie eines zweiten Durchlaufs darüber. Man erkennt dann, dass z.B. im Bereich direkt unter dem gerenderten Motorrad beide Bilder ein unterschiedliches Rauschen zeigen. Die Differenz zwischen beiden Codepfaden ist kleiner als dieses Rauschen und somit nicht nachweisbar.
4 Schlussfolgerungen und Quellen
Generell eröffnen sich aus den Ergebnissen zwei grundlegende Fragen hinsichtlich der „Fairness“ von CPU-Benchmarks:
a) Sind Benchmark-Ergebnisse vergleichbar, wenn sie je nach Prozessor unterschiedliche Maschinenbefehle für den gleichen Algorithmus verwenden?
Darüber kann man unterschiedlicher Meinung sein. Ich persönlich tendiere zu einem „ja“ um die evolutionäre Weiterentwicklung des Befehlssatzes von Prozessoren abzubilden. Man müsste dann diese Optimierung aber auch für alle Prozessorhersteller freigeben, was zur zweiten Fragen führt.
b) Welcher Grad von Transparenz ist für die Wahl der Codepfade bzw. des genutzten Befehlssatzes (SSE, AVX, …) bei einer bestimmten CPU nötig?
Der auf einem Prozessor genutzte Befehlssatz für das Programm (und die vielen, vielen Unterfunktionen) liegt in den Händen des Compilers und ist vom Programmierer auf Ebene seiner Hochsprache (z.B. C++) nicht einzusehen. Insofern dürfte es schwierig sein, dort verlässliche Angaben zu machen, da kein Programmierer den erzeugten Maschinencode per Hand liest. Ohne ein passendes Analysewerkzeug zur Überprüfung des gesamten Codes ist dies nicht zu stemmen, da viel zu aufwändig. Das Manipulieren von ein paar Zieladressen um einen extrem seltenen cpuid-Befehl ist dann eben doch etwas anderes.
Insofern bleibt aus meiner Sicht nur der Test von fertigen Benchmarks hinsichtlich herstellerspezifischer Optimierungen. Der dargelegte Weg ist manuell durchgeführt zu aufwändig, so dass er automatisiert werden müsste. Weiterhin ist auch festzuhalten, dass böswillige Manipulationen sich damit nicht aufdecken lassen. Maschinencode kann z.B. erst zur Laufzeit entschlüsselt und dann ausgeführt werden.
Im speziellen Fall von Cinebench R10 ist die Bewertung der Ergebnisse zudem hinsichtlich der Anwendungsrelevanz des Benchmarks komplizierter: Für Ersteller computeranimierter Filme sind die Stromkosten der Rendermaschinen ein wesentlicher Kostenfaktor. Zur Kostenminimierung wird dann natürlich der bestmögliche Kompiler eingesetzt, welcher von Intel stammt. Wenn sich dessen Kompilate immer so verhalten wie Cinebench R10, misst es für diesen speziellen Anwendungsfall Rendering richtig.
Die meisten Anwendugsprogramme für Windows werden jedoch immer noch mit Microsoft-Compilern erstellt. Somit ist die vom Cinebench Hersteller Maxon propagierte Anwendungsrelevanz des Benchmarks doch überzogen dargestellt [golem]:
Quellen
[ArsTechnica] – http://arstechnica.com/gadgets/2008/07/atom-nano-review/6/
[OnlineAssembler] – https://defuse.ca/online-x86-assembler.htm
[cpuid] – http://www.lowlevel.eu/wiki/CPUID
[XOR] – http://andremueller.gmxhome.de/befehle.html
[golem] - http://www.golem.de/0708/54002.html
Anhänge
Zuletzt bearbeitet:
E555user
Admiral Special
- Mitglied seit
- 05.10.2015
- Beiträge
- 1.551
- Renomée
- 593
Hallo miriquidi
vielen Dank für die Analyse, leider wird soetwas von den bekannten sogenannten IT-Redaktionen nicht behandelt.
Was neben den direkten Code-Optimierungen IMHO mindestens genauso ins Gewicht fällt sind die Architektur bzw. CPU-Design abhängigen Besonderheiten.
So hat Intel seit langem schon mittels schneller und immer grösseren OnDie Caches die Ausführung von Code beschleunigt. Das kommt allerdings in den meisten Anwendungsfällen nicht so deutlich zum tragen wie in diversen Benchmarks oder Computerspielen. AMD konnte wohl wegen der Fertigungstechnik stets nur kleinere Caches verbauen. Wenn nun im Extrem ein Benchmark bei einer CPU komplett in den Caches läuft und bei der anderen CPU häufig RAM-Zugriffe verursacht, dann ist das ein erheblicher Nachteil. Auch deshalb denke ich, dass z.B. Cinebench eben kein guter Benchmark ist um die generelle Leistungsfähigkeit eines Systems oder CPU zu bewerten. Ich kann mich vage an Zeitschriftentests vor vielen Jahren erinnern, bei denen zum benchen bewusst Caches deaktiviert wurden, um deren Einfluss zu berücksichtigen. Wir diskutierten damals allerdings noch Pentium und PentiumPro AFAICR. Aber beispielsweise die allgemeine Erkenntnis, dass aktiviertes Hyperthreading bei bestimmtem Code auch mal Nachteile generiert zeigt überdeutlich, dass der Code nunmal mehr oder weniger auf bestimmte Architekturen hin optimiert werden kann und wird, das kann auch ganz unabsichtlich geschehen einfach weil eine bestimmte CPU in der Entwicklung eingesetzt wird.
Im Endeffekt bräuchte es statt Einzel-Tests eher Testsuiten, bei denen man die relevanten Applikationen je nach Bedarf testet. Und das sieht nunmal für diverse Typen von Anwendern und Konsumenten sehr unterschiedlich aus. Cinebench ist doch eigentlich nur für die Nutzer von Maxon Software interessant
vielen Dank für die Analyse, leider wird soetwas von den bekannten sogenannten IT-Redaktionen nicht behandelt.
Was neben den direkten Code-Optimierungen IMHO mindestens genauso ins Gewicht fällt sind die Architektur bzw. CPU-Design abhängigen Besonderheiten.
So hat Intel seit langem schon mittels schneller und immer grösseren OnDie Caches die Ausführung von Code beschleunigt. Das kommt allerdings in den meisten Anwendungsfällen nicht so deutlich zum tragen wie in diversen Benchmarks oder Computerspielen. AMD konnte wohl wegen der Fertigungstechnik stets nur kleinere Caches verbauen. Wenn nun im Extrem ein Benchmark bei einer CPU komplett in den Caches läuft und bei der anderen CPU häufig RAM-Zugriffe verursacht, dann ist das ein erheblicher Nachteil. Auch deshalb denke ich, dass z.B. Cinebench eben kein guter Benchmark ist um die generelle Leistungsfähigkeit eines Systems oder CPU zu bewerten. Ich kann mich vage an Zeitschriftentests vor vielen Jahren erinnern, bei denen zum benchen bewusst Caches deaktiviert wurden, um deren Einfluss zu berücksichtigen. Wir diskutierten damals allerdings noch Pentium und PentiumPro AFAICR. Aber beispielsweise die allgemeine Erkenntnis, dass aktiviertes Hyperthreading bei bestimmtem Code auch mal Nachteile generiert zeigt überdeutlich, dass der Code nunmal mehr oder weniger auf bestimmte Architekturen hin optimiert werden kann und wird, das kann auch ganz unabsichtlich geschehen einfach weil eine bestimmte CPU in der Entwicklung eingesetzt wird.
Im Endeffekt bräuchte es statt Einzel-Tests eher Testsuiten, bei denen man die relevanten Applikationen je nach Bedarf testet. Und das sieht nunmal für diverse Typen von Anwendern und Konsumenten sehr unterschiedlich aus. Cinebench ist doch eigentlich nur für die Nutzer von Maxon Software interessant
Es stimmt, dass man manchmal durch die Wahl des Algorithmus (bzw. seiner Feinabstimmung) zu völlig verschiedenen Ergebnissen kommt.
Nur sollten bei Benchmarks ja die Aufgaben an realen Problemen angelehnt sein, insofern sollte man Algorithmen vermessen, die real auftreten. Ein gutes Beispiel sind hier evtl. Audio-Encoder. Falls MP3-Encoding auf Intel CPUs schneller läuft als auf AMD CPUs und sich bei OGG jedoch beide nicht viel nehmen, kann ich deswegen doch nicht die Benchmark-Zusammensetzung zu OGG ändern.
Es stimmt aber, dass die meisten Programmierer ihren Algorithmus natürlich auf Geschwindigkeit fein tunen. Wenn man Probleme zerlegt, optimiert man z.B. die Blockgröße der Zerlegung. Das macht man meist auf einer Intel-CPU und stellt dann eine optimale Blockgröße ein. Mache ich selbst auch so.
Das mit den Caches stimmt übrigens quantitativ nicht. Die von der K7-CPU abstammenden CPUs hatten immer recht große Caches verglichen mit den Pentium-Pro-Erben. Schnell waren aber höchstens die ersten beiden Stufen. Erst seit den Bulldozer-Kernen sieht das etwas anders aus.
Testsuiten gibt es auch: Sysmark 2014. Dort dominieren jedoch auch Einzelprogramme die Punktwertung; zudem kostet das Benchmark Geld und ist somit nicht einfach mal überprüfbar. Mich würde aber schon interessieren, warum dort Adobe-Produkte und Excel die Punktewertung dominieren.
Nur sollten bei Benchmarks ja die Aufgaben an realen Problemen angelehnt sein, insofern sollte man Algorithmen vermessen, die real auftreten. Ein gutes Beispiel sind hier evtl. Audio-Encoder. Falls MP3-Encoding auf Intel CPUs schneller läuft als auf AMD CPUs und sich bei OGG jedoch beide nicht viel nehmen, kann ich deswegen doch nicht die Benchmark-Zusammensetzung zu OGG ändern.
Es stimmt aber, dass die meisten Programmierer ihren Algorithmus natürlich auf Geschwindigkeit fein tunen. Wenn man Probleme zerlegt, optimiert man z.B. die Blockgröße der Zerlegung. Das macht man meist auf einer Intel-CPU und stellt dann eine optimale Blockgröße ein. Mache ich selbst auch so.
Das mit den Caches stimmt übrigens quantitativ nicht. Die von der K7-CPU abstammenden CPUs hatten immer recht große Caches verglichen mit den Pentium-Pro-Erben. Schnell waren aber höchstens die ersten beiden Stufen. Erst seit den Bulldozer-Kernen sieht das etwas anders aus.
Testsuiten gibt es auch: Sysmark 2014. Dort dominieren jedoch auch Einzelprogramme die Punktwertung; zudem kostet das Benchmark Geld und ist somit nicht einfach mal überprüfbar. Mich würde aber schon interessieren, warum dort Adobe-Produkte und Excel die Punktewertung dominieren.
hoschi_tux
Grand Admiral Special
Beim CB10 kann man erkennen, dass AMD recht gut mit Intel mithalten kann. Beim 15er stellt sich wieder eine größere Lücke ein, wie beim 10er anfangs. Kannst du da für den 15er auch noch eine solche Analyse machen oder sind da derartige cpuid Aufrufe nicht mehr vorhanden? Wie sieht das bei anderen Benchmarks aus der Zeit aus (auch 3Dmark z.B.)?
E555user
Admiral Special
- Mitglied seit
- 05.10.2015
- Beiträge
- 1.551
- Renomée
- 593
Hallo miriquidi
Da bin ich ganz bei dir, die Cache-Grössen sind AFAIK erst mit Intel Core2 rasant angestiegen und wohl Teil der Strategie nach dem Pentium4 Desaster gewesen. Mit PentiumPro wollte ich nur zeitlich die Ära der wahrscheinlich letzten objektiven CPU-Reviews und ernsthaften Analysen verorten
weil ich grad drüber gestolpert bin:
Im Benchvergleich hier in den News ist der Carrizo mit neuem Coredesign gegenüber dem Kaveri bei Cinebench im SingleThread viel besser und kann das im MultiThreading bei diesem Cinebench nicht mehr umsetzen. Ich spekulier mal einfach ins Blaue und würde annehmen, dass das mit dem besseren L1 Cache des Excavator im SingleThread zusammen hängt, und im Multithreading der L2 dann doch mit 2MB statt zuvor 4MB einfach wieder zu klein ausgefallen ist.
Wie auch immer zeigt genau dieser Vergleich, dass gerade Cinebench einfach kein gut veralgemeinbarer Richtwert für die Leistungsfähigkeit von CPUs ist. Der Excavator scheint doch sonst durch die Bank besser als der Vorgänger.
Zuletzt bearbeitet:
@hoschi_tux: Technisch gesehen nutzt Cinebench R15 anstatt x86 ja x86-64 Code. Da bräuchte man einen neuen Disassembler.
Rechtlich gesehen wird man das wohl nicht mehr deassemblieren dürfen, insofern sollte man dort nur auf Maschinencode-Ebene arbeiten (das geht auch).
Zeitlich gesehen bekomme ich das in nächster Zeit nicht auf die Reihe. Wer will, soll sich versuchen. Ich helfe auch gerne mir Rat.
3DMark könnte man machen, da es x86-Code ist. Ich halte es aber für nicht sehr interessant, da es ja eher ein GPU-Benchmark ist. Sysmark wäre der interessanteste von allen Kandidaten, das kostet aber zu viel.
Rechtlich gesehen wird man das wohl nicht mehr deassemblieren dürfen, insofern sollte man dort nur auf Maschinencode-Ebene arbeiten (das geht auch).
Zeitlich gesehen bekomme ich das in nächster Zeit nicht auf die Reihe. Wer will, soll sich versuchen. Ich helfe auch gerne mir Rat.
3DMark könnte man machen, da es x86-Code ist. Ich halte es aber für nicht sehr interessant, da es ja eher ein GPU-Benchmark ist. Sysmark wäre der interessanteste von allen Kandidaten, das kostet aber zu viel.
hoschi_tux
Grand Admiral Special
Und der 11.5er? Von dem gibt es noch 32Bit Executables.
Da könnte man es mit der Deassembler-Methode machen. Die Softwaretools sind frei erhältlich und alle oben im Text beschrieben.
Ob man es darf, ist ne andere Frage. Müsste man in der Lizenzbestimmung nachsehen, ob Deassemblieren verboten ist.
Ob man es darf, ist ne andere Frage. Müsste man in der Lizenzbestimmung nachsehen, ob Deassemblieren verboten ist.
Ich habe mit dem Hex-Editor Bless gerade die "CINEBENCH Windows 64 Bit.exe" geöffnet und mich mal etwas umgesehen. Mittels des Online Assemblers kann man ja mal ein paar typische Codesequenzen von Assembler in Maschinencode transferieren. Sucht man z.B. nach der Sequenz 0fa289 (<- hexadezimal) findet man schon einige CPU-ID abrufe als Maschinencode. Wer will kann dort ja einfach mal ein paar Modifikationen vornehmen und das Ergebnis mit dem Originalzustand vergleichen.
Übrigens gibt's in der besagten .exe auch den String "GenuineIntel". Gleich daneben existiert der String "AuthenticAMD". Es scheint, als erkennt Cinebench zumindest beide Prozessorhersteller. Das alte Cinebench R10 kannte nur den Intel, nicht jedoch den AMD-String.
Übrigens gibt's in der besagten .exe auch den String "GenuineIntel". Gleich daneben existiert der String "AuthenticAMD". Es scheint, als erkennt Cinebench zumindest beide Prozessorhersteller. Das alte Cinebench R10 kannte nur den Intel, nicht jedoch den AMD-String.
