Wird AMD permanent gegenüber Intel in Reviews benachteiligt? Bitte ersten post lesen

[mr.dude]

Du hast es nicht verstanden ...

Nein, du hast es nicht verstanden. Nochmal ganz deutlich, du vergleichst UNTERSCHIEDLICHE BUILDS. Und das ist bei dieser Diskussion ziemlich belanglos, da wir beim Vergleich unterschiedlicher CPUs und eventuellen unverhältnismäszigen Unterschieden immer vom selben Build ausgehen. Ich frage mich echt, was du hier überhaupt beweisen willst. Vermutlich weisst du das selbst nicht mal.

Yonah ist nicht Pentium M

Wüsste nicht, dass das jemand behauptet hätte. Yonah (Core) war aber nun mal der Vorgänger von Merom (Core2) und unterscheidet sich vom Pentium-M lediglich dadurch, dass es ein Dualcore Design mit angepasstem Cache ist. IPC Unterschiede sind daher auch kaum vorhanden.




So, für alle die es interessiert (auch speziell für unseren desillusionierten Freund Undertaker 1) wie versprochen verschiedene Lame Builds, damit man mal einen kleinen Einblick gewinnen kann, was unterschiedliche Compiler und Mikrooptimierungen für Auswirkungen haben. Verwendet wurde GCC (MinGW 4.3.1 TDM-1) und Microsoft Compiler (15.00.21022.08). Die Dateien des Intel Compiler entsprechen den downloadbaren Binaries. Für FP habe ich immer jeweils eine Version mit Legacy Code (x87) und eine mit SSE bereitgestellt. Einmal wurde das normale Lame in der aktuellsten Version (3.98) und einmal die Version des separaten MT Projektes (3.97 alpha 2) verwendet. Umgewandelt wurde eine 35 MB Wave Datei. Folgende Systeme kamen dabei zum Einsatz:

AMD X2 5000+ @ 1666 MHz
2 GB DDR2 667 @ 333 MHz DRAM / 5-5-5-15
Windows XP Pro 32 Bit SP3

Intel T5500 @ 1666 MHz
1 GB DDR2 667 @ 333 MHz DRAM / 5-5-5-15
Windows Vista Home Premium 32 Bit SP1

Ok, hier die nackten Zahlen (play/cpu):

AMD

Lame 3.98

ICC = 10.754
GCC Pentium M x87 = 10.744
GCC Pentium M SSE = 9.8096
GCC K8 x87 = 10.919
GCC K8 SSE = 9.8934
GCC Core2 x87 = 10.744
GCC Core2 SSE = 9.7125
GCC K10 x87 = 10.995
GCC K10 SSE = 9.3560
MSC = 7.8757
MSC SSE = 5.9379

Lame MT 3.97 alpha 2

ICC = 13.858
GCC Pentium M x87 = 15.126
GCC Pentium M SSE = 14.231
GCC K8 x87 = 15.437
GCC K8 SSE = 14.623
GCC Core2 x87 = 15.019
GCC Core2 SSE = 14.183
GCC K10 x87 = 15.494
GCC K10 SSE = 13.295
MSC = 13.769
MSC SSE = 11.891

Intel

Lame 3.98

ICC = 13.919
GCC Pentium M x87 = 11.603
GCC Pentium M SSE = 11.406
GCC K8 x87 = 11.560
GCC K8 SSE = 11.275
GCC Core2 x87 = 11.593
GCC Core2 SSE = 11.386
GCC K10 x87 = 11.582
GCC K10 SSE = 10.798
MSC = 10.663
MSC SSE = 8.1973

Lame MT 3.97 alpha 2 (--mt --nores)

ICC = 17.595
GCC Pentium M x87 = 15.710
GCC Pentium M SSE = 16.502
GCC K8 x87 = 15.710
GCC K8 SSE = 14.817
GCC Core2 x87 = 15.672
GCC Core2 SSE = 16.632
GCC K10 x87 = 15.710
GCC K10 SSE = 16.147
MSC = 17.123
MSC SSE = 15.632

Was lässt sich nun aus diesen Zahlen ablesen? Erstmal sollte man diese nicht überbewerten. Andere Compilereinstellungen und schon kann es wieder anders aussehen. Was aber auffällt, ist die Diskrepanz zwischen x87 und SSE. Während der K8 mit x87 schneller ist, sieht es beim Core2 relativ ausgeglichen aus. Ein Tribut an die 2x64 Bit Aufteilung der SSE Pipeline beim K8. Unterschiede sind also rein architektonisch begründet. Was auch auffällt, ICC und MSC optimieren weit weniger für AMD. Ob hier unterschiedliche Codepfade oder ähnliches zum Einsatz kommen, oder für Intel einfach ein deutlich höherer Optimierungsgrad implementiert wurde, lasse ich einfach mal aussen vor. Dass erstes allerdings nicht unwahrscheinlich ist, sieht man zB an den Ergebnissen des GCC im Vergleich zu ICC und MSC. Oder anders formuliert, ICC und MSC könnten es besser, wenn sie denn wöllten.

Wie man sieht, kommen entsprechende Compiler zum Einsatz, können schnell mal nicht unerhebliche Unterschiede entstehen. So liegt beim Test auf CB zwischen einem Athlon 4050e (2,1 GHz) und einem E6420 (2,13 GHz) ca. 35-45% IPC Unterschied. Kommt hingegen ein weitestgehend neutraler Compiler wie der GCC zum Einsatz, sind es gerade mal 5-15% IPC Unterschied (siehe oben). Wobei die 2 MB mehr L2 Cache des E6420 gegenüber dem T5500 und der Unterschied von DDR2 gegenüber DDR3 noch zu beachten ist.

Und dies ist nur eines von etlichen Beispielen in unzähligen Tests, die das Pendel zugunsten von Intel ausschlagen lassen. Und ob dann einfach zu wenige Optimierungen für die jeweilige Architektur in die Implementation einfliessen oder schnellere Routinen absichtlich geblockt werden, ist eigentlich nur noch zweitrangig. Beides ist in jedem Fall vorsätzlich.

Wer selbst mal etwas rumspielen möchte, für den habe ich ein Paket mit allen Binaries hier hochgeladen. Vielleicht findet sich noch jemand mit K10 Vergleichswerten.

[daysleeper83]

Wer selbst mal etwas rumspielen möchte, für den habe ich ein Paket mit allen Binaries hier hochgeladen. Vielleicht findet sich noch jemand mit K10 Vergleichswerten.

Mache ich gleich mal, Ergebnisse folgen

Phenom K10 @ 1.625 GHz / NB : 2GHz / Speicher 2* DDR2 1000 (unganged)
Testdatei: test.wav (34,7 MB)

Lame 3.98

gcc core2 x387 : 12.829x
gcc core2 SSE : 11.583x

gcc k8 x387 : 12.791x
gcc k8 SSE : 11.790x

gcc K10 x387 : 12.891x
gcc K10 SSE : 12.362x

gcc pentium-m x387 : 12.397x
gcc pentium-m SSE : 11.706x

icc : 13.293x
msc : 9.3565x
msc_SSE : 7.3429x

Lame 3.97 alpha

gcc core2 x387 : 13.169x
gcc core2 SSE : 12.198x

gcc k8 x387 : 13.051x
gcc k8 SSE : 11.568x

gcc K10 x387 : 13.155x
gcc K10 SSE : 12.288x

gcc pentium-m x387 : 12.653x
gcc pentium-m SSE : 12.209x

icc : 13.195x
msc : 11.302x
msc_SSE : 10.316x

[mr.dude]

Yep, danke. Interessant zu sehen, dass beim GCC die K10 Optimierungen schon gut greifen. Speziell bei der aktuellen Lame Version liegen x87 und SSE nahe beieinander.

Ach übrigens, ich hatte vergessen zu erwähnen, lame-mt muss mit folgenden Kommandozeilenparametern gestartet werden:

--mt --nores

Dann sollte auch Multithreading und die Verwendung von mehr als einem Kern greifen.

[daysleeper83]

Lame 3.97 alpha --mt --nores

gcc core2 x387 : 18.664x
gcc core2 SSE : 17.575x

gcc k8 x387 : 18.824x
gcc k8 SSE : 16.040x

gcc K10 x387 : 18.824x
gcc K10 SSE : 17.597x

gcc pentium-m x387 : 18.507x
gcc pentium-m SSE : 17.348x

icc : 18.637x
msc : 17.768x
msc_SSE : 16.356x

Dude kannst ja mal versuchen diese Funktion in den Source Code unterzubringen, das sollte den Intel Dispatcher überschreibern

#include "asmlib.h"
extern "C" {
int __intel_cpu_indicator = 0;
void __intel_cpu_indicator_init() {
// Get CPU level from asmlib library function
int cpulevel = InstructionSet();
switch (cpulevel) {
case 0: // No special instruction set supported
__intel_cpu_indicator = 1;
break;
case 1: case 2: // MMX supported
__intel_cpu_indicator = 8;
break;
case 3: // SSE supported
__intel_cpu_indicator = 0x80;
break;
case 4: // SSE2 supported
__intel_cpu_indicator = 0x200;
break;
case 5: // SSE3 supported
__intel_cpu_indicator = 0x800;
break;
case 6: case 7: // Supplementary-SSE3 supported
__intel_cpu_indicator = 0x1000;
break;
case 8: case 9: // SSE4.1 supported
__intel_cpu_indicator = 0x2000;
break;
case 10: default: // SSE4.2 supported
__intel_cpu_indicator = 0x4000;
break;
}
}
121
} // End of extern "C"

Nach Agner sollst du static linking benutzen (sagt mir gerade mal Überhaupt nix) asmlib.h findest du hier (www.agner.org/optimize/asmlib.zip). Habs gestern mit dem Visual Studio versucht ist mit aber dauernd während der Konvertierung in ein IntelC++ Projekt abgeschmiert :/.

[mr.dude]

Ich lade mir mal die 30 Tage Testversion des Intel Compilers runter und schaue, ob ich den Code einbinden kann.

[Mondrial]

Muss ich dir etwa noch vorlesen was da steht? "Sie [Core2] stellt ein Mix aus den besten Komponenten der Core-Duo- und NetBurst-Architektur dar"

Und weiter steht da: " mit Schwerpunkt auf dem Core-Duo-Design" Geht jetzt schon das selektive Zitieren wie zu besten StevensDE-Zeiten los?

Vergleiche doch einfach auch mal die IPC-Entwicklung von K8 zu K10 sowie die von Banias zu Penryn, die Differenzen sind klarstens sichtbar.

Was sagen IPC Verbesserungen über Evolution oder Revolution bei CPUs aus?

[daysleeper83]

Im Gegensatz zur Cinbebench ist Cinema 4D nicht, jedenfalls nicht nur mit dem ICC compiliert, hier machen auch Opterons eine gute Figur. Nur der Cinebench benachteiligt alle außer Intel.

Cinema4d hat freundlicherweise die Demo zur Version 11.0 online gestellt, für Testzwecke hab ich fix mal Bike.c4d in Cinebench10 und Cinema4d 11.0 Demo durchlaufen lassen.

Cinebench 10 : 1min 36 sek
Cinema4d 11 : 49 sek

Ausgedrückt in CB-CPU Punkten sind das in etwas 19.000

Macht mal eben fast die doppelte Performance... ich bin begeistert

[CyLord]

Warte erstmal ab, bis jemand seine Ergebnisse des Core2Duo postet, dann sollte man einen besseren Überblick haben.

[daysleeper83]

Warte erstmal ab, bis jemand seine Ergebnisse des Core2Duo postet, dann sollte man einen besseren Überblick haben.

Jojo kein Stress, freu mich nur weil ich Cinema4d selber nutze und der Geschwindigkeitsunterschied wirklich enorm ist

[che new]

Cinebench 10 : 1min 36 sek
Cinema4d 11 : 49 sek

Ausgedrückt in CB-CPU Punkten sind das in etwas 19.000

Nette (Phenom?)Optimierungen die da gemacht wurden.
Jetzt bräuchten wir noch nen Core2-Wert (am besten 65nm und 45nm) um zu sehen wie stark dieser noch zulegen konnte.

Edit: Kann man die Demo nur bei Maxon herunterladen? Der ftp Server scheint down zu sein...

[daysleeper83]

http://www.maxon.net/pages/download/downloads_d.html

Man muss sich nur anmelden

Dann die Datei \plugins\bench\bike\bike.c4d (von Cinebench10) laden, "Render View" klicken und Zeit stoppen. Kannst auch gerne mal mit dem K8 probieren würde mich interessieren.

Edit : hier ein direct download
ftp://ftp.maxon.net/pub/r11/CINEMA4DR11.zip (funzt einwandfrei)

[che new]

Hab mich schon angemeldet, aber scheinbar ist der Server momentan down. Da geht momentan gar nix, egal welches Programm man downloaden will. Wäre interessant ob der K8 auch zugelegt hat.

[daysleeper83]

Hmm bei mir geht der Link ohne Probleme sogar relativ fix (500kb/s)

[F-kopp]

bei mir gehts auch.

[Chrisch]

Hab zwar keinen Quad, aber habs mal mitm 4Ghz E8600 probiert...

Cinebench R10 = 1min 45sek
Cinema 4D 11 = 45sek

Edit: Auflösung auf 800x600 angepasst und Cinema 4D Ergbnis korrigiert.

[daysleeper83]

Was ich vergessen hab ihr müsst die outputfile noch abändern auf die Auflösung des Cinebench 10 Bildes welches 800 mal 600 beträgt.

Ctrl+B und Auflösung ändern
dann
Shift+R

[Chrisch]

Dann komme ich mitm 4Ghz E8600 auf 45sek in Cinema 4D 11, also schneller als dein 2.65Ghz (?) Phenom.

[daysleeper83]

Hab mit 2.5 GHz getestet (Vista64) mit angepasster Einstellung brauch ich 40 sek.

[Chrisch]

Ok, du hast sogar noch den 64bit vorteil

Bin gespannt wann hier nen Ergebnis von nem Yorkfield auftaucht

[che new]

Dennoch scheint es so als ob der Core2 (45nm) stärker von den Optimierungen profitiert, bei CB 10 lag er noch hinter dem Phenom, nun vor dem Phenom.

[daysleeper83]

War doch schon immer so (SSE4) is mir auch wurscht, ich finds nur krass was man mit guter Software aus einem Prozessor rausholen kann.

[Wiking]

Der Link zur Cinema 4D 11 Demo ist tot. Kennt jemand einen Alternativlink?

[Chrisch]

google hilft da ganz gut

[mr.dude]

So, ich habe jetzt alle Lame Ergebnisse pro Compiler und CPU mal zusammengefasst.

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:

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:

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.

[daysleeper83]

Vielleicht mit Linpack ?

http://www.intel.com/cd/software/pro...eng/363184.htm ah seh gerade gibts nur als binary