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

Status
Für weitere Antworten geschlossen.
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Also so einfach wars dann doch nicht mit dem HEX Code zumindest zeigt es keine Unterschiede. Da lame ja als src code vorliegt müsste man aber eigentlich eine Abfrage patchen können.. probiere das dann mal .
Hinzugefügter Post:
Nö, nutzen alle maximal SSE2 :)

Exakt, der Code von Lame unterstüzt maximal SSE2.
 
Zuletzt bearbeitet:
Ist Deneb nicht K10.5?

Auch wenn es ne rhetorische Frage ist, ja.

Edit: Ich weiß schon was jetzt kommt, aber ein Shanghai/Deneb ist eben immer noch ein K10-basierter Opteron/Phenom, nur in 45nm. So wie ein Penryn ein Core 2 Duo in 45nm ist.
 
Zuletzt bearbeitet:
Also der Intel Compiler verweigert seinen Dienst mit Visual Studio 8 Express.. der weiß wohl was ich vorhab :hmm:. Gibts irgendwo noch ne Free Trial von der 5.0 Version?
 
Jupp

Mal ein bißchen OT Maxon bringt bald Cinema4d 11 (September) raus uns siehe da auf der CPU supported list steht auch der K10 :)

CPU Mindestanforderung für CINEMA 4D R11 und BodyPaint 3D R4

Unterstützte Prozessoren

* Intel Pentium M
* Intel Pentium 4
* Intel Pentium 4D
* Intel XEON
* Intel Core Solo
* Intel Core Duo
* Intel Core 2 Duo
* Intel Core 2 Quad
* Intel Celeron
* Intel Celeron D
* AMD Sempron (K8)
* AMD Athlon XP (K8)
* AMD Athlon MP
* AMD Opteron
* AMD Phenom

Mal schauen wie sich das auswirkt
 
Zuletzt bearbeitet:
Dir ist schon klar, dass sich mit unterschiedlichen Versionen die Performance verschiedener CPUs relativ zueinander verändert hat? Damit ist der Beweis erbracht, dass die getroffenen Optimierungen der einen CPU besser schmecken als der anderen
Was irgendwie ziemlich offtopic ist. Die Basis für einen Vergleich sind immer noch identische Builds.

somit das Verhalten von CPU a mit Optimierung a nicht auf CPU b übertragen werden kann. Ein Test mit dem Nano um Rückschlüsse auf eine AMD-CPU zu ziehen ist somit wertlos. Dies nun zum 10. Male :)
Erstmal ist hier überhaupt nichts zu beweisen, siehe oben. Und zum 1000. Male, darum geht es nicht. Wann kapierst du das endlich? Soll ich dir das schriftlich geben? :rolleyes:
Nochmal ganz deutlich, es geht um "GenuineIntel" vs Non-"GenuineIntel", nicht um AMD vs "GenuineIntel". Welche CPU wie reagiert, ist dann von Fall zu Fall zu unterscheiden. Der Schwerpunkt der Diskussion bleibt aber der, dass Nicht-Intel CPUs benachteiligt werden, egal welche das auch ist. Also tue uns bitte den Gefallen und höre endlich mit deiner sinnlosen Beitragsflut auf.
Und dass sich Mikrooptimierungen von CPU zu CPU nicht auswirken, hat auch niemand behauptet. Du solltest schon sachlich bleiben. Tatsache ist aber, dass sich Mikrooptimierungen in überschaubaren Grössenordnungen bewegen und nicht einfach mal so 50% mehr Leistung bringen (siehe pcmark05), oder was auch immer für Vorstellungen du haben magst. Bei pcmark05 kann man sicher davon ausgehen, dass unterschiedliche Codepfade verwendet wurden. Und wie man Intel kennt, ist das Absicht. Und das wird sich bei AMD ähnlich auswirken wie bei VIA. Da braucht man kein Prophet zu sein. Es gibt mittlerweile mehr als genug Beispiele, wo man gut sehen kann, was unterschiedliche Codepfade des ICC bei AMD bewirken.

Btw, werde, falls ich heute noch dazukomme, lame mit einer aktuellen mingw Version (evtl. auch MSC) kompilieren. Einmal mit K8/K10 und einmal mit Pentium-M/Core2 Optimierung. Dann kannst du dich selbst mal davon überzeugen, was Mikrooptimierungen bringen. Bei deinem Beispiel ist nämlich eher die Frage, was der ICC bei MT wieder für Tricks macht.

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"

Vergleiche doch einfach auch mal die IPC-Entwicklung von K8 zu K10 sowie die von Banias zu Penryn, die Differenzen sind klarstens sichtbar.
Und wo sind da die Revolutionen? IPC hat sich von Yonah zu Merom in etwa gleichem Verhältnis geändert wie von K8 zu K10. Was nicht sonderlich verwunderlich ist, da sich diverse Leistungsfaktoren in ähnlichem Verhältnis geändert haben. Was genau willst du uns eigentlich erzählen?
 
Was irgendwie ziemlich offtopic ist. Die Basis für einen Vergleich sind immer noch identische Builds.

Du hast es nicht verstanden. Es ging um die relative Geschwindigkeitsentwicklung verschiedener CPUs zueinander zwischen den Versionen. Bei allgemeinen Optimierungen, wie von dir zuerst behauptet, wäre der Unterschied konstant geblieben. Deine These ist damit als falsch widerlegt.

Erstmal ist hier überhaupt nichts zu beweisen, siehe oben. Und zum 1000. Male, darum geht es nicht. Wann kapierst du das endlich? Soll ich dir das schriftlich geben? :rolleyes:
Nochmal ganz deutlich, es geht um "GenuineIntel" vs Non-"GenuineIntel", nicht um AMD vs "GenuineIntel". Welche CPU wie reagiert, ist dann von Fall zu Fall zu unterscheiden. Der Schwerpunkt der Diskussion bleibt aber der, dass Nicht-Intel CPUs benachteiligt werden, egal welche das auch ist. Also tue uns bitte den Gefallen und höre endlich mit deiner sinnlosen Beitragsflut auf.
Und dass sich Mikrooptimierungen von CPU zu CPU nicht auswirken, hat auch niemand behauptet. Du solltest schon sachlich bleiben. Tatsache ist aber, dass sich Mikrooptimierungen in überschaubaren Grössenordnungen bewegen und nicht einfach mal so 50% mehr Leistung bringen (siehe pcmark05), oder was auch immer für Vorstellungen du haben magst. Bei pcmark05 kann man sicher davon ausgehen, dass unterschiedliche Codepfade verwendet wurden.

Begründe mal diese Grenze. 14% sind es bei 2 verschiedenen Lame-Versionen. In einem Extremfall schreibe ich ein Programm so das es exakt mit den 12MB Cache eines Yorkfield auskommt und hätte somit einen gigantischen Geschwindigkeitsschub gegenüber allen CPUs, die auf den Ram zugreifen müssten. Oder ich versuche einen sehr FPU-lastigen Quelltext zu schreiben, wenn ich den Phenom stärker dastehen lassen möchte. Allein z.B. für die Berechnung der Zahl Pi gibt es ein dutzend verschiedener mathematischer Reihen, die verschiedenste Rechenoperationen nutzen, es ist durchaus denkbar das auf einer CPU das schnellste Verfahren ein anderes ist als auf einer zweiten. Wenn jetzt mittels unterschiedlicher Codepfade auf jeder CPU das jeweils schnellste genutzt wird, ist das absolut zulässig und mit einer dritten CPU in keiner Weise untersuchbar.

Und wie man Intel kennt, ist das Absicht.

Unsachlich.

Und wo sind da die Revolutionen? IPC hat sich von Yonah zu Merom in etwa gleichem Verhältnis geändert wie von K8 zu K10. Was nicht sonderlich verwunderlich ist, da sich diverse Leistungsfaktoren in ähnlichem Verhältnis geändert haben. Was genau willst du uns eigentlich erzählen?

Yonah ist nicht Pentium M :)
 
Zuletzt bearbeitet:
Jupp

Mal ein bißchen OT Maxon bringt bald Cinema4d 11 (September) raus uns siehe da auf der CPU supported list steht auch der K10 :)



Mal schauen wie sich das auswirkt

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.
[...]
Yonah ist nicht Pentium M :)

Yonah ist sehr wohl ein 65nm PentiumM-Shrink, nur eben als Doppelkern mit geteiltem Cache und darüber laufender Kohärenz. Nur der Name ist anders. Yonah ist immernoch nur nativ 32Bittig und hat genau die gleichen Auführungseinheiten. Ich wette, auch die internen Latenzen sind fast gleich.
 
Zuletzt bearbeitet:
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.

Nope, Cinema4d rendert das Cinebench Bike Modell genaus so schnell wie Cinebench selber, gibt da kein Geschwindigkeitsunterschiede. Trotzdem möglich das einige Module besser mit dem K8/K10 arbeiten kann ich gerne mal nachprüfen.
 
Zuletzt bearbeitet:
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. :rolleyes:

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):
Code:
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.
 
Zuletzt bearbeitet:
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
 
Zuletzt bearbeitet:
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:
Code:
--mt --nores
Dann sollte auch Multithreading und die Verwendung von mehr als einem Kern greifen.
 
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 :/.
 
Zuletzt bearbeitet:
Ich lade mir mal die 30 Tage Testversion des Intel Compilers runter und schaue, ob ich den Code einbinden kann.
 
Zuletzt bearbeitet:
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? :stupid:

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?
 
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 :d :bigok:
 
Zuletzt bearbeitet:
Warte erstmal ab, bis jemand seine Ergebnisse des Core2Duo postet, dann sollte man einen besseren Überblick haben.
 
Cinebench 10 : 1min 36 sek
Cinema4d 11 : 49 sek

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

:eek: Nette (Phenom?)Optimierungen die da gemacht wurden. :coolblue:
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...
 
Zuletzt bearbeitet:
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.
 
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.
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh