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

Status
Für weitere Antworten geschlossen.
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
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Dann komme ich mitm 4Ghz E8600 auf 45sek in Cinema 4D 11, also schneller als dein 2.65Ghz (?) Phenom.
 
Hab mit 2.5 GHz getestet (Vista64) mit angepasster Einstellung brauch ich 40 sek.
 
Ok, du hast sogar noch den 64bit vorteil ;)

Bin gespannt wann hier nen Ergebnis von nem Yorkfield auftaucht :)
 
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.
 
Zuletzt bearbeitet:
War doch schon immer so (SSE4) is mir auch wurscht, ich finds nur krass was man mit guter Software aus einem Prozessor rausholen kann.
 
google hilft da ganz gut :wink:
 
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.
 
Zuletzt bearbeitet:
Da momentan wieder mein Abit-Board mit 630a-Chipsatz, welches im BIOS die Deaktivierung von "SSE/SSE2" erlaubt, verbaut ist, habe ich mal spaßeshalber die CPU Test Suite von PCMark05 mit und ohne SSE-Einheiten laufen lassen.


SSE/SSE2 im BIOS disabled



SSE/SSE2 im BIOS enabled



Später werde ich noch weitere Test Suites laufen lassen, mal sehen ob es überhaupt einen Bench bei PCMark05 gibt bei dem die SSE-Einheiten (von AMD-CPUs) genutzt werden.

Ne Warnmeldung dass PCMark05 ohne SSE nix proper läuft gibts beim Tool-Start zumindest schon mal. Fragt sich nur warum eigentlich (bisher)? :fresse:
 
Zuletzt bearbeitet:
Sehr schönes Feature deines Boards. Mal schauen, ob ich mein BIOS noch dahingehend patchen kann. Die Idee hatte ich nämlich auch schon. Im laufenden Betrieb SSE zu deaktivieren, geht anscheinend schon mal nicht. Zumindest quittiert mir das Windows immer mit einem BSOD. :d Ich bin mir allerdings immer noch nicht sicher, ob ich auch die richtigen MSWs erwischt habe. Leider gibt es nur sehr wenige Unterlagen dazu.
 
Gab doch auch ein Board, bei dem man SSE3 ausschalten konnte. Bzw. bei dem es automatisch disabled war und man es auch im Bios anstellen musste..kein Plan ist lange her.
 
sry, ich blick da grad nicht durch:confused:
wegen was sse deaktivieren? Was wollt ihr damit erreichen?
Und ja ich kenne den Threadtitel, deswegen die Frage
 
Das soll zeigen, dass es wurscht ist ob enabled oder disabled, der Benchmark nutzt es bei AMD einfach nicht.
 
exakt und das ist gerade der Beweis, den einige nicht war haben wollen.
kannst du das noch bei einigen Programmen wieder holen? z.b. Cinebench
 
@hydrotoxin
SSE sorgt bekanntlich für deutliche Leistungsschübe, speziell wenn vektorisierte Instruktionen zum tragen kommen (aber nicht nur). Wenn man SSE also deaktiviert und keine Leistungsunterschiede zu sehen sind, kann man davon ausgehen, dass mit aktiviertem SSE die komplette Funktionalität nicht genutzt wird. Das ganze lässt sich natürlich nur auf Anwendungen übertragen, die auch wirklich von SSE profitieren.
 
wäre mal interesant zu wissen wie das ganze bei Intel dann aussehen würde.

Jedoch würde das doch eigentlich etwas gutes für AMD heißen, wenn die Optimierenungen nicht benutzt werden. Ohne Optimierungen oft mals nahe so schnell wie Intel mit Optimierungen.

Oder nicht?
 
Yep, das ist der Grundgedanke. Und wie du sagst, man müsste noch jemand finden, der das mit einem Intel System gegentestet. Ich habe zwar eines hier. Daran möchte ich aber lieber nicht rumfummeln, speziell am BIOS, da es ein Notebook ist.
 
Zuletzt bearbeitet:
wie könnte man das den testen? Bis jetzt kenn ich kein Intel Board, wo man das abschalten bzw einschalten kann im BIOS.
 
Erstmal müsste man klären, ob es bei Intel überhaupt möglich ist. Dann könnte man sich auf die Suche nach einem entsprechenden BIOS machen. Oder wer entsprechend versiert ist, eines dahingehend ändern.
Bei AMD erreicht man die Deaktivierung von SSE zB über die Änderung eines MSW Bits. Das wird im Fall von che new's BIOS sicherlich auch gemacht.
 
@mr.dude
Ich war sogar der Meinung dass mir das Feature schon öfter über den Weg lief, weiß leider nicht mehr welche Boards das noch waren.

@Fairy Ultra
Cinebench 10 startet ohne SSE leider nicht... aber ich werde noch andere Programme testen, ihr könnt mir ruhig paar Ideen geben was ich testen soll ;)
btw, SuperPi zeigt absolut keinen Ergebnisunterschied zwischen SSE aktiv/SSE inaktiv, was aber eigentl. klar war.

Edit: Werde mal bissl recherchieren, vielleicht findet sich ein S775-Board bei dem SSE/SSE2 ebenfalls deaktiviert werden kann. Notfalls bestell ich mir dann jenes Board inkl. günstigem Core2-Kastrat.
 
Zuletzt bearbeitet:
na das erste wäre erstmal 3dmark , der CPU Score

kommt ja aus dem selben hause wie pcmark
 
Wieso bin ich da nicht selber drauf gekommen... :d

Übrigens weder Cinebench 2003, CB 9.5 noch Cinema4D 11 starten ohne SSE.
 
Übrigens weder Cinebench 2003, CB 9.5 noch Cinema4D 11 starten ohne SSE.
Auf das Problem wirst du vermutlich noch öfters stossen. Hier müsste man einfach mehr Kontrolle haben. ZB gezielt SSE Versionen oder vektorisierte Instruktionen deaktivieren. Das ist allerdings nicht möglich.
 
deswegen kann man nur immer weiter bestrebt sein open source programme zu fördern den da kannst du selbst kompilieren und sicherstellen das keine versteckten Tricks angewendet werden.
 
Bringt nur nix für Max Mustemann der von compilieren noch nie was gehört hat und es wahrscheinlich mit irgendeiner neumodischen Sex Art verbindet :hmm:.
 
Es würde ja schon helfen, wenn sich GCC auch in der Windows Welt durchsetzt (unter Linux Quasi Standard). Das Problem bisher war vor allem, mal abgesehen davon, dass es immer noch Beschränkungen beim Windows SDK und DDK gibt, dass der Compiler eine ziemlich mangelhafte Performance lieferte. Ich bin allerdings mehr als positiv überrascht, welche Fortschritte seit Version 4 gemacht wurden.
 
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