Allgemein
Knowledge Base
- Neue Struktur (In Arbeit)
- Computertechnisches
Community
Privat
/ HomePage / Computer / Hardwareübersicht / PC-Zentraleinheit / Benchmarks / FreeBench
http://www.freebench.org
war eine kleine Suite von synthetischen CPU-Benchmarks. Die Seite ist leider aus unbekannten Gründen eingestellt worden. Die Website ist dank archive.org aber noch verfügbar.
Hier gehts zur ehemaligen freebench.org seite
Der mit den Programmen ermittelte Wert stellt den Geschwindigkeitsfaktor gegenüber einer Sun Ultra 10 - 333 MHz dar, die scheinbar ungefähr so schnell wie ein Pentium III 500 MHz ist.
Moderne Mehrkern-CPUs werden dabei nur mit einem Kern berücksichtigt, also quasi die Minimalleistung. Interessant ist auch der Unterschied zwischen verschiedenen Compilern. Der Intel C-Compiler erzeugt teilweise erheblich schnellereren Code als der gcc.
Hier ist die neue Tabelle, sämtliche Daten wurden aus der alten Tabelle übernommen, die neue Tabelle ist PHP/MySQL gestützt, läßt sich über eine Eingabemaske erweitern, und beliebig sortieren.
Update:
Update2:
Kommentar Eigentlich war es nur mal ein Versuch mit PHP etwas rumzuspielen, daß am Ende was brauchbaren dabei herauskam ist ein netter Nebenaspekt.
Bei den Pentium 4 Tests kann man schön sehen, dass der Unterschied zw. den Architekturen nicht sonderlich hoch ist. Soll heißen, es spielt fast keine Rolle ob für Pentium4 (-march=pentium3 -mcpu=pentium4
) oder für die Allgemeinheit (-march=i586
) gebuildetkompiliert wird. Wobei letzteres auch noch auf dem einfachen Pentium 1 läuft.
Noch etwas hat sich bewahrheitet. Der gcc
erzeugt falschen Code, wenn nur -march=pentium4
eingestellt ist, der Benchmark hat Prüfsummen eingebaut, die am Ende feststellen können, ob ein Test fehlerfrei durchgelaufen ist. Und an einer Stelle macht er das bei (-march=pentium4
) nicht.
Der FreeBench Test sollte nicht unter X11 mit KDE durchgeführt werden, es hat es sich gezeigt, dass das mehr als 5% Rechenzeit kosten kann, ohne dass etwas am Rechner getan wird.
Hier sehr gut zu sehen, wie gut VMware wirklich ist. Die CPU wird absolut top emuliert. Ich frage mich, wie die das hinbekommen.
icc
ist der Intel Compiler version 7 oder 8, der ist z.Z. leider nur für Benchmarks gut, nicht für den Rest wie Kernel, KDE, X11, mplayer, ... für Gentoo gibt es ein USE-Flag icc und icc-pgo um dann einige Pakete mit dem icc übersetzen zu lassen. Welche das sind ist mir nicht bekannt. Zudem ist die Optimierung (-O3) nicht viel besser als beim
gcc
, es sei denn, feedback optimizations werden genutzt.
Jetzt ist beim P4 ein direkter Vergleich von icc7 zu icc8 möglich, man sieht das einige Tests sehr viel schneller geworden sind, leider sind einige auch schlechter geworden. Trotzdem sind 9% schnellerer Code über alle Tests, nur weil ein neuer Compiler genommen wurde, schon nicht schlecht. Obwohl eigentlich nur die Tests Mason und DistRay richtig schneller geworden sind. Anbei sieht man auch, das der gcc durchaus in der Lage ist dem icc noch paroli zu bieten.
Bei den feedback-optimierungen erzeugt der compiler beim ersten Durchlauf des Programmes eine Profil-datei und kann erst danach beim 2. kompiliervorgang richtig optimieren. Diese technik beherrscht sowohl der icc
als auch der gcc
.
Das Makefile
von Freebench surgerriert durch das Vorhandensein der Variablen PROF_GEN
und PROF_USE
eine Unterstützung dieses Verfahrens, tatsächlich wird aber der Code nicht für die Profilgenerierung durchlaufen, man muss es also von Hand machen. Das bedeutet dass der Benchmark zwei mal ausgeführt werden muss, beim ersten mal mit den Compiler-switches zum Erstellen eines profils und beim zweiten mal mit den Schaltern zum Benutzen des Profils.
Profil Erzeugen:
gcc: -fprofile-generate
icc: -prof_dir /tmp/prof -prof_gen
Profil Benutzen:
gcc: -fprofile-use
icc: -prof_dir /tmp/prof -prof_use
Die Ergebnisse sind teilweise beachtlich, jedoch sind einige Tests auch geringfügig langsamer als vorher.
Hier sieht man, das der Compiler wohl noch nicht ganz fehlerfrei arbeitet. Wobei ich mich dann frage, überhaupt auf AMD64 umzusteigen, wohl nur um mal ein paar AMD64 Benchmarks zu fahren. Wobei der -O2 Schalter zu funktionieren scheint. Vielleicht der selbe Fehler wie beim K6-III, muss mal geprüft werden.
-O3
Optimierung scheint auf den gcc 3.4.3 mehr als fehlerhaft zu arbeiten. Gentoo Wiki empfiehlt auch nur -O2
. In gcc 4.1.2 ist dies offenbar behoben, -O3
kann benutzt werden und produziert auch geringfügig schnelleren Code als -O2
.
Der schnelle ist mit dem QEMU-Accelerator erstellt worden, der langsame mittels parameter -no-kqemu. Im direkten Vergleich dazu habe ich das Image auch mal mit vmware durchlaufen, Qemu ist nicht langsamer.
Oder neu gegen alt... Was für eine Krücke hatte Intel bloß mit dem Pentium 4 damals gebaut. Mein (Lars) Core Duo U2500 (1.2GHz) ist ca. ~1.755x schneller als ein Pentium 4 (1.8GHz) was mir sagt: Um diesem P4 das selbe Ergebnis zu entlocken, müsste er mit fast 3.2GHz laufen
Nicht vergessen, gcc 3.4.6 Compiler Zahlen vergleichen!!! Der ICC Compiler von Intel ist besser als der gcc.
Der Analyser Test scheint komplett im 2MB Cache zu laufen, da der Core Duo U2500 (1.2GHz) hier das zweitbeste Ergebnis liefert. Dank an Elsni für den Core 2 Duo Test, der das nochmals bestätigt.
Ich (Lars) habe mit meinem Opteron und dem gcc 4.1.2 ein paar Tests gefahren und den FreeBench in verschiedenen Optimierungsstufen laufen lassen. Der Default von 100% liegt bei -O2, wie man sieht bringt -O3 nur marginale 2% mehr, -O1 ist nur ~2% langsamer und die Turbo Optionen würde ich niemanden empfehlen, wer weiß, wie stabil ein System mit solchen Einstellungen wirklich liefe. Obwohl 14% mehr schon nicht schlecht sind, das entspreche einem Opteron mit ~2.5GHz bei -O2 Optimierung.
Nachtrag Intel Compiler: Ein paar neue Werte ermittelt mit dem aktuellen icc 10.1 sind hinzugekommen. Es ist schon erschreckend, das ein anderer Compiler noch so viel bessere Werte herauskitzeln kann, lassen wir die feedback optimisations mal beiseite sind es 43% mehr gegenüber gcc 4.1.2 mit -O2, umgerechnet entspräche das etwa einem Opteron mit 3.1GHz.
Nachtrag GCC 4.2.2: Der gcc 4.2.2 ist gegenüber dem gcc 4.1.2 in diesem Benchmark ungefähr 3,7% schneller. Grob entspricht das, bei 1 Stunde Laufzeit einer Verbesserung von etwas mehr als 2 min.
Nachtrag GCC 4.3.1: Der gcc 4.3.1 ist gegenüber dem gcc 4.1.2 in diesem Benchmark ungefähr 10(16)% schneller. Grob entspricht das, bei 1 Stunde Laufzeit einer Verbesserung von etwas mehr als 6(10) min. Oder einer Taktsteigerung von 2.2GHz auf etwas über 2.4GHz. Wobei die Optimierungen noch mit Vorsicht zu genießen sind, der gcc 4.3.1 macht bei -O2 & -O3 beim Distray-Test Fehler. Aber selbst mit -O1 ist das Resultat immer noch 10% schneller als beim gcc 4.1.2 mit -O2. Damit kann man sagen, der neue gcc 4.3.1 hat einen riesigen Schritt nach vorne gemacht. Hut ab.
Nachtrag GCC 4.3.2: Der gcc 4.3.2 kitzelt noch mehr Leistung aus dem Benchmark. Die Einstellung -O3 + -march=opteron erzeugt fehlerhaften Code unter x86-32 beim Distray Test. Distray funktioniert aber mit -march=athlon-4 und -march=prescott. z.Z. scheint die Prozessoreinstellung -march=prescott die beste Einstellung für 32bit zu sein, holt sie doch nochmal ~1.6% besseren Code heraus.
Nachtrag GCC 4.4.0: Der gcc 4.4.0 ist zwar noch nicht ganz fertig für Gentoo, kitzelt aber wiederum noch mehr Leistung aus dem Benchmark. Der Distray Test erzeugt weiterhin fehlerhaften Code und wird nur mit -O1 laufen gelassen. Ansonsten wurde der Test mit -O3 -march=prescott -fomit-frame-pointer getestet. Während der fourinarow Test exorbitant gewinnt, verlieren die Floating Point Tests alle etwas.
System |
Optionen |
Ø gcc 4.1.2 |
Ø gcc 4.2.2 |
Ø gcc 4.3.1/2 |
Ø gcc 4.4.0 |
Ø icc 10.1 |
Opteron 175 |
-O0 -march=opteron -fomit-frame-pointer |
4.198 (61%) |
4.243 (62%) |
4.286 (62%) | ||
-O1 -march=opteron -fomit-frame-pointer |
6.759 (98%) |
7.557 (110%) | ||||
-O2 -march=opteron -fomit-frame-pointer |
6.888 (100%) |
7.145 (104%) |
7.843 (114%) | |||
-O3 -march=opteron -fno-inline-functions -fomit-frame-pointer |
7.025 (102%) |
7.293 (106%) |
8.186 (119%) | |||
-O3 -march=i486 -fomit-frame-pointer |
7.844(114%) | |||||
-O3 -march=athlon-4 -fomit-frame-pointer |
8.196 (119%) | |||||
-O3 -march=prescott -fomit-frame-pointer |
8.334 (121%) | |||||
-O3 -march=prescott -fomit-frame-pointer |
8.527 (123%) | |||||
-O3 -march=prescott -fomit-frame-pointer |
8.539 (124%) | |||||
-s -static -O3 -fno-inline-functions -march=athlon-4 -msse3 |
7.848 (114%) |
8.079 (117%) | ||||
icc 10.1.008 / -O3 |
8.479 (123%) | |||||
icc 10.1.008 / -O3 -march=pentium4 -axN |
9.878 (143%) | |||||
icc 10.1.008 / -O3 -march=pentium4 -axN |
10.216 (148%) |
Auf einem Intel Core-2-Duo liegen Welten zwischen dem gcc 4.1.2 und dem icc 10.1. Der icc ist im 64bit-Modus bei normalen Einstellungen (d.h. ohne die Optimierung komplett auszuschalten) mindestens 14% schneller, mit feedback-optimization und core-2 code sogar bis über 50%.
Ein Test mit feedback-optimization im gcc 4.1.2 machte das Programm zwar auch ein ganzes Stück schneller, kam aber trotzdem bei weitem nicht an die -O3
Optimierung des icc 10.1 heran.
Der gcc 4.2.2 lieferte sowohl mit als auch ohne feedback-optimierung nahezu identische Ergebnisse zum 4.1.2, die innerhalb der normalen Ausführungstoleranzen liegen. Scheinbar wurde an der Codegenerierung nichts geändert. Die Hoffnung, die neuen Optionen -march=native -mtune=native
würden schnelleren Code erzeugen, wurde leider nicht bestätigt.
Compiler |
Optionen |
Ø-Wert |
% |
gcc 4.1.2 |
-march=nocona |
6.116 |
62% |
icc 10.1 |
-O0 |
6.333 |
65% |
gcc 4.1.2 |
-march=nocona -O2 |
9,757 |
100% |
gcc 3.3.6 |
-march=nocona -O3 |
9.850 |
101% |
gcc 4.1.2 (nahezu gleiche Werte mit gcc 4.2.2, egal ob -march=nocona oder -march=native) |
-march=nocona -O3 |
10.473 |
107% |
gcc 4.1.2 (gleicher Wert mit gcc 4.2.2) |
-march=nocona -O3 (feedback-optimization) |
11.917 |
122% |
icc 10.1 |
-O3 |
14.824 |
152% |
icc 10.1 |
-xT |
14.898 |
152% |
icc 10.1 |
-xT (feedback-optimization) |
15.803 |
163% |