So, ich habe jetzt alle Lame Ergebnisse pro Compiler und CPU mal zusammengefasst.
Code:
Lame K8->Core2 K8->K10 Core2->K10
ICC +29% +27% -2%
GCC +11% +23% +11%
MSC +37% +24% -9%
Lame MT K8->Core2 K8->K10 Core2->K10
ICC +27% +38% +9%
GCC +8% +25% +16%
MSC +28% +37% +7%
Moment mal, ganz so einfach ist das natürlich nicht. Wir vergleichen hier einfach Dualcores und Quadcores, lassen Cachegrössen oder höher getaktete Modelle ausser Acht, usw. Ok, schauen wir uns mal einiges an.
Stichwort Cache. Dazu hat THG
hier einiges getestet. Von 1 auf 2 MB beträgt der Unterschied bei Lame -0,4%, von 1 auf 4 MB -0,6%. Mehr Cache bringt also offenbar kaum Mehrleistung. Zumindest nicht bei Intel. Bei AMD ist Cache bekanntlich noch weniger relevant und dürfte daher auch kaum Unterschiede zeigen.
Wie sieht es nun mit dem Takt aus. Auch da hat THG eine hilfreiche
Übersicht. Zwischen E2140 (1,6 GHz) und E6850 (3 GHz) liegen 87,5% Taktunterschied. Die dort gemessenen Zeiten, 272 Sekunden für E2140 und 144 Sekunden für E6850 ergeben einen Unterschied von knapp 89%. Die Taktskalierung ist praktisch linear.
Wie sieht es nun mit der Nutzung mehrerer Kerne aus? Lame nutzt lediglich einen Kern. Selbst ein Dualcore bringt hier keine Mehrleistung. Etwas anders sieht es bei Lame MT aus. Allerdings werden auch hier nur maximal zwei Kerne genutzt. Quadcores bringen daher ebenfalls keine Mehrleistung. Schauen wir deshalb nochmal zu CB.
Hier sieht man, dass vergleichbare Dual- und Quadcores (E6600/Q6600, E6750/Q6700, E6850/QX6850) immer gleich schnell sind.
Als letztes noch eine Übersicht mit Ergebnissen verschiedener RAM Taktungen, die ich gemessen habe:
Code:
Athlon X2 5000+ @ 2000 MHz
Lame 3.98
2 MB DDR2 @ 200 MHz DRAM
ICC = 12.872
GCC Pentium M x87 = 12.936
GCC Pentium M SSE = 11.799
GCC K8 x87 = 13.136
GCC K8 SSE = 11.898
GCC Core2 x87 = 12.910
GCC Core2 SSE = 11.690
GCC K10 x87 = 13.260
GCC K10 SSE = 11.267
MSC = 9.4812
MSC SSE = 7.1510
2 MB DDR2 @ 400 MHz DRAM
ICC = 12.963
GCC Pentium M x87 = 12.963
GCC Pentium M SSE = 11.821
GCC K8 x87 = 13.164
GCC K8 SSE = 11.920
GCC Core2 x87 = 12.950
GCC Core2 SSE = 11.723
GCC K10 x87 = 13.301
GCC K10 SSE = 11.287
MSC = 9.5093
MSC SSE = 7.1670
Man sieht, auch von schnellerem RAM profitiert Lame kaum.
@daysleeper83
Ich habe Lame mit dem aktuellen ICC und dem Quellcode von dir kompiliert. Allerdings kannst du die Funktion
__intel_cpu_indicator_init nicht einfach so einbinden. Die Funktion ist bereits in der Runtime Bibliothek
libirc.lib definiert (Module cpu_disp.c), welche immer dazugelinkt wird. Ein erneutes Definieren würde damit gegen die
ODR verstossen. Musste daher erst das Symbol in der Bibliothek ändern, dann klappte es. Habe danach jeweils zwei Kompilate non-SSE und SSE für das ungepatchte und gepatchte Lame erstellt. Hier die Ergebnisse:
Code:
AMD X2 5000+ @ 1666 MHz
ICC = 10.699
ICC SSE = 9.1610
ICC patched = 10.610
ICC SSE patched = 9.1876
Intel T5500 @ 1666 MHz
ICC = 13.593
ICC SSE = 13.172
ICC patched = 13.607
ICC SSE patched = 13.239
Hat insgesamt also keine Auswirkungen auf die Mikrooptimierungen zwischen den verwendeten CPUs. Allerdings sollte man auch bedenken, SSE wird erst richtig bei vektorisierten Instruktionen interessant. Dazu ist Lame nicht besonders repräsentativ.
Trotzdem noch ein interessantes Detail am Rande. Ich habe mir den Wert der Variablen
__intel_cpu_indicator bei allen Kompilaten vor der Änderung ausgeben lassen. Bei Intel war dieser immer 4096 (0x1000). Laut dem Quellcode Support bis SSSE3. Bei AMD war dieser Wert immer 1, also "no special instruction set supported". In der gepatchten Version wurde dieser Wert dann korrekterweise auf 2048 (0x800) gesetzt, also Support bis SSE3.
Sollte Intel tatsächlich über diese Variable bestimmte Optimierungen steuern, wäre das natürlich eine klare Beschränkung für Nicht-Intel CPUs. Aber dazu müsste man noch weitere Anwendungen testen. Speziell solche, die massiv von SIMD profitieren und kaum handgeschriebene Assembler Routinen verwenden.