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

[Undertaker 1]

Ich habe schon viele vergleichbare Core2- und X2-Systeme getestet und durchgemessen, stets darauf bedacht keine Ausreisser-Boards zu verwenden und möglichst den Einfluss von Drittkomponenten gering zu halten. Es hat sich mir immer das gleiche Bild gezeigt, die Core2-Systeme haben im Leerlauf eine merkliche höhere Leistungsaufnahme.
Mein geposteter Test mit picoPSU zeigt doch unmissverständlich, selbst wenn man die CPUs extrem undervoltet (so dass deren reale Verlustleistung maximal noch 1-2W betragen kann), man vergleichbare Chipsätze mit nahezu identischer Ausstattung verwendet, die übrigen Komponenten kaum Einfluss haben (HDD-> 1W, Lüfter -> ~0,5W, RAM -> ~1,5W) und das NT kaum noch Verluste durch Wirkungsrad aufweist, ist der Abstand zwischen AMD und Intel immer noch deutlich im Leerlauf. Vielleicht hast du ja ne Idee was diese Differenz ausmacht.

Natürlich, durch den hungrigen G33 Und Ich habe schon mehrfach erwähnt, dass bei IGP ein AMD-System sparsamer ist. Mit dem Verbrauch des MC hat das aber nicht viel zu tun.

Wäre nicht das erste Mal das Praxistests den Herstellerangaben widersprechen. Ich stehe mit dieser Meinung nicht alleine da, andere User sind zum gleichen Entschluss gekommen, vorwiegend jene die selbst einen Vergleich durchgeführt haben. Als recht deutlichen Hinweis für den Laien kann man auch die größeren (NB)Kühlkörper der 780G-Boards im Vergleich zu den 690G– und 630a-Boards sehen.

Wenn man sieht, was verschiedene Boards mit gleichen Chipsätzen für unterschiedliche Kühlkörper haben, ist es wohl schwer daraus auf den Verbrauch zu schließen.

Die Leistung der Systeme ist für mich erstmal sekundär, ich habe mir das Intel-System so zusammengestellt, weil es die sparsamsten S775-Komponenten waren die man zu dem Zeitpunkt bekommen konnte (E7200 war noch nicht erhältlich, würde am Endergebnisse auch nicht viel ändern). Mir ging es nicht um einen Direktvergleich Leistung pro Watt, sondern welches System sparsamer sein kann, insbesondere im Leerlauf.

Der E8500 war zu keiner Zeit die sparsamste verfügbare CPU auf Intelseite, soviel schoneinmal vorweg. Trotzdem, die Sache mit dem Verbrauch bei Chipsätzen mit IGP hab ich ja schon einige Mal erwähnt, hier wird ein AMD-System trotzdem vorne liegen, zweifellos - wenn auch etwas weniger als in deinem Test, aber hier brauchen wir jetzt wohl keine Absolutwerte zu spekulieren.

Dass ich vor dem Optimieren erstmal Messungen @Default mache ist für mich selbstverständlich. Es ist sowieso nicht relevant wie stark eine CPU ist, im Leerlauf sind fast alle modernen DC-CPUs fast ähnlich hungrig. Ein E8500 sollte im Leerlauf sogar Vorteile bei der realen Verlustleistung gegenüber dem X2 BE-2400 habe. Die Lastwerte hätte ich wohl besser weglassen sollen, nur hätte das bei dem einen oder anderen auch für etwas Beigeschmack gesorgt.

Jo, das war OK so.

Letztendlich zeigt der Test, dass bei S775 schlichtweg nicht weniger geht, man kann sich auf den Kopf stellen, wirklich unter 25W wird man nicht kommen... (Hard)Voltmod ausgeschlossen.

Auch hier, Zustimmung bis auf den Punkt das 1. eine CPU <E8500 nochmal ein wenig sparsamer gewesen wäre und 2. bei den Minimalmessungen (also mit Untertaktung) insbesondere ein Absenken des FSB erhebliche(!) Vorteile gebracht hätte, bei dennoch weiterhin besserer Leistung auf Intelseite - das AMD-System wäre aber wohl trotzdem noch vorne geblieben, aber nichtmal das ist wirklich sicher. Was ich die ganze Zeit nur gesagt habe, ist dass die Situation bei Verwendung einer kleinen Grafikkarte, z.B. weil weitere Anschlüsse benötigt werden, auf jeden Fall ausgeglichener ist.

Lies dir dieses Posting durch, dort solltest du die nötigen Links finden. http://www.forumdeluxx.de/forum/showpost.php?p=9569270&postcount=70

Schau mal bei deinem verlinkten HT4U Review, was das andere Board idle im Maximalfall (X2 6000+) ausmacht: Ganze 1,7W...

 

[mr.dude]

Insofern, wo liegen für dich die genauen Kritikpunkte?

Mir fehlen bei vielen Seiten zB Tests auf 64 Bit Systemen. Viele Leute wissen vermutlich nicht mal, dass Intel hier einige Architekturschwächen hat. Mehr dazu auch hier. Das wurde zB bei den CB Redakteuren auch schon des öfteren bemängelt. Da kommen dann aber immer nur so geistreiche Antworten wie, das sei nicht praxisrelevant, da nur sehr wenige Leute überhaupt 64 Bit Systeme einsetzen. Was erstens nicht stimmt und zweitens CB nicht davon abhält, Intel Systeme schon länger komplett auf DDR3 Basis zu testen.

Die erstmals beim AMD Phenom eingeführte Variante SSE4.1A, die sich von Intels SSE4 unterscheidet und nicht kompatibel ist, wird aktuell noch nicht unterstützt. Deshalb kann dieser nur im SSE2-Modus getestet werden.

Hier sieht man leider auch wieder mal die Inkompetenz von CB ganz deutlich. Erstmal heisst das SSE4a. Oder von mir aus auch SSE4A. Und das hat auch nicht im entferntesten etwas mit SSE4.1 von Intel zu tun. Also selbst wenn µCode technisch AMD unterstützt werden würde, heisst das noch lange nicht, dass AMD genauso profitiert. CB sagt das so zwar nicht direkt, impliziert es aber. SSE4a ist nur eine Art minimales SSE3 Update. Genau genommen sind es 4 Instruktionen für Bit Manipulation und 2 Instruktionen, um Daten aus Registern direkt in den Speicher zu schreiben, ohne den Umweg Cache wie sonst üblich. Allerdings lassen sich damit auch recht nette Leistungsgewinne erzielen, sofern genutzt. Intels SSE4 konzentriert sich hingegen auf String Manipulation, was man natürlich auch für andere sequenzielle Daten nutzen kann.

Weißt du eig. was für ein Schwachsinn povray ist?
Povray nutzt die eig. Vorteile von SSE nicht, wie z.B. Vektoren, Matritzen....

Das stimmt, povray hat halt eine sehr alte Codebasis. Trotzdem würde ich es nicht als Schwachsinn bezeichnen. AFAIK kommt bei povray auch nicht allzu viel Assemblercode zum Einsatz, hängt also stark am Tropf des Compilers. Man muss sich einfach damit abfinden, dass der Code Intel zugute kommt. Selbst der P4 lief hier schon besser. Einfach nicht als allgemeingültig betrachten und fertig. Leider sind viele "Bild Leser", die dann mit den hübschen Benchmark Balken argumentieren, zu solch differenzierter Betrachtung nicht im Stande. Das ist eigentlich die Crux an der Geschichte. Für Hobbyisten ist povray als Anwendung selbst jedenfalls recht nett.

 

[F-kopp]

7zip profitiert nicht von MultiCores.
Es skaliert ab 2 Kernen überhaupt nicht mehr.

zB hier:
.....


.....
nur 11 sek(8%) schneller als ein 200MHz langsamerer dualcore mit einem 1/3 des Caches. (QX9770 vs E6850)

Und deswegen darf es nicht getestet werden...?

Am besten sollte man beides benchen und auf die Probs bei 7zip hinweisen.
Einem einfach so den 7zip-Bench an den Kopf zu klatschen ist der worst case.

 

[Undertaker 1]

Ups sry, dass kam beim quoten vorhin erst nach dem anderen Text Da hast du recht, beides testen und auf die jeweilige Besonderheiten hinweisen (einmal nur der geringe Quadcoresupport, einmal die große Speicherabhängigkeit) wäre wohl die objektivste und beste Variante, da sind wir auf gleicher Linie.
Auf der anderen Seite ist dies, wenn keines der beiden Programme getestet wird, auch keine Benachteiligung eines einzelnen Herstellers.

 

[Mondrial]

Oder noch präziser: 7-Zip profitiert von Cache, Takt und Speicherperformance und bei Winrar kommen mehr Kerne und das native Design zur Geltung...

Auf der anderen Seite ist dies, wenn keines der beiden Programme getestet wird, auch keine Benachteiligung eines einzelnen Herstellers.

Falsch, denn der Architekturvorteil eines Herstellers wird verschwiegen...

 

[mirko10]

Also kommt der Vorsprung nur durch den doppelten Cache...unbrauchbar für einen guten Vergleich.


Es ging um den Hinweis...lies doch mal richtig

Und ebenfalls mit Version 4.42, die über 2 Jahre alt ist. Versuchs mal mit einer aktuelleren Version, dann werden wir sehen ob es da genauso aussieht.

 

[[HOT]]

Ups sry, dass kam beim quoten vorhin erst nach dem anderen Text Da hast du recht, beides testen und auf die jeweilige Besonderheiten hinweisen (einmal nur der geringe Quadcoresupport, einmal die große Speicherabhängigkeit) wäre wohl die objektivste und beste Variante, da sind wir auf gleicher Linie.
Auf der anderen Seite ist dies, wenn keines der beiden Programme getestet wird, auch keine Benachteiligung eines einzelnen Herstellers.

Meine Rede, das ist auch genau das, was ich von einer guten Review verlange. Man kann benchen was man will (vorasgesetzt man hat ein hinreichend durchdachtes Repertoire von unterschiedlichen Programmen herausgesucht), aber man sollte auf jeden Fall die jeweiligen Gegebenheiten untersuchen und analysieren können und die bekannten bzw. festgestellten Eigenheiten bei dem festgelegten Zahlenwerk festhalten.
Ich bin auch absolut dafür, Benchmarks wie Cinebench, Povray oder SuperPI zu verwenden, solange man deren Eigenheiten klar herausstellt und aufzeigt, wo die Probleme sind. Aufklärung des Lesers ist immer die beste Variante, viel besser als Propaganda durch Halbwahrheiten, weil der Reviewer keine Zeit/Lust/Kompetenz hat.

 

[daysleeper83]

http://www.xtremesystems.org/forums/showthread.php?t=196616

Was eine CPUID so ausmachen kann

 

[F-kopp]

Meine Rede, das ist auch genau das, was ich von einer guten Review verlange. Man kann benchen was man will (vorasgesetzt man hat ein hinreichend durchdachtes Repertoire von unterschiedlichen Programmen herausgesucht), aber man sollte auf jeden Fall die jeweiligen Gegebenheiten untersuchen und analysieren können und die bekannten bzw. festgestellten Eigenheiten bei dem festgelegten Zahlenwerk festhalten.
Ich bin auch absolut dafür, Benchmarks wie Cinebench, Povray oder SuperPI zu verwenden, solange man deren Eigenheiten klar herausstellt und aufzeigt, wo die Probleme sind. Aufklärung des Lesers ist immer die beste Variante, viel besser als Propaganda durch Halbwahrheiten, weil der Reviewer keine Zeit/Lust/Kompetenz hat.

Da haste Recht.

Aber ich lege meine Hand dafür ins Feuer, dass selbst wenn derart nach deinen Wünschen gebencht wird, weiterhin Intelfanboys mit den Graphen/Diagrammen ankommen und behaupten werden, dass Intel ja soooo viel besser sei, da die eh nur auf die balken gucken und keine Zeile Text lesen.

 

[che new]

@daysleeper83

Poste das bitte im Nano vs. Atom Thread, wird dort sicher noch mehr Leute interessieren.

Das relativiert so einige Ergebnisse des VIA Nano 1,8GHz. Einfach nur arm von den Beteiligten.

 

[F-kopp]

http://www.xtremesystems.org/forums/showthread.php?t=196616

Was eine CPUID so ausmachen kann

Dazu hatte ich auch schon mal einen Thread gestartet...
Unteranderem auch wegen den Vektoroptimierung, die zu 99% nur für die Intel CPUs vorgenommen werden und weil dummerweise AMDs k10 / k8 anadauernd mit Intel-compiler Software gebencht wurde.

Eig. waren sich da alle einig, dass das Beschiss von lobbyistenverseuchten möchtegern-Fachblättern ist.

Bis auf ein paar Intelhardliner halt...

 

[Undertaker 1]

http://www.xtremesystems.org/forums/showthread.php?t=196616

Was eine CPUID so ausmachen kann


http://www.abload.de/img/776_pcm2k5_24rp.jpg

Wie wärs, wenn du als Phenom-Nutzer einfach mal deine CPUID änderst und schaust, ob das mit einer AMD-CPU in aktuellen Programmen auch so aussieht? Der Nano ist 3 Jahre neuer als der PCM05, ggbnfls. schmeckt ihm der Intelpfad einfach besser...
Wenn allerdings z.B. ein 3DM Vantage bei einem Phenom mit Intel-CPUID bessere Ergebnisse ausspuckt als ohne, würde ich in der Tat absolut von Cheat sprechen - also ran an den Speck, dann wissen wir mehr

 

[daysleeper83]

Das geht nich bei AMD, die CPUID ist gelockt soweit ich weiß.
Hinzugefügter Post:

? Der Nano ist 3 Jahre neuer als der PCM05, ggbnfls. schmeckt ihm der Intelpfad einfach besser...

Geht ja nicht nur um den Nano

"Second, there's the issue of performance when Nano is identified as AuthenticAMD. If performance between the AMD and Intel CPUIDs was identical, there wouldn't really be a story here, but it isn't, and that's curious"

 

[Undertaker 1]

Irgendwie etwas merkwürdig. Von einer dort getesteten AMD-CPU mit Intelpfad kann ich nix lesen, nach deiner Aussage kann man da ja die ID nicht ändern. Und das der Nano mit AMD-Pfad langsamer ist kann wie erwähnt daran liegen, das seine Architektur mehr derer ähnelt, auf die der Intelpfad optimiert ist... Oder wie würdest du das interpretieren? Mir leuchtet es nicht ganz ein, ehrlich.

 

[daysleeper83]

Irgendwie etwas merkwürdig. Von einer dort getesteten AMD-CPU mit Intelpfad kann ich nix lesen, nach deiner Aussage kann man da ja die ID nicht ändern. Und das der Nano mit AMD-Pfad langsamer ist kann wie erwähnt daran liegen, das seine Architektur mehr derer ähnelt, auf die der Intelpfad optimiert ist... Oder wie würdest du das interpretieren? Mir leuchtet es nicht ganz ein, ehrlich.

Es geht ja darum, dass der AMD Pfad gegenüber dem Intel so dermaßen schlecht ist und genau über diese "Optimierung" kann man sich an dieser Stelle streiten. Der Test indiziert ja das für Intel wesentlich mehr optimiert wurde als für AMD. Wieweit das Architektur abhängig ist kann genauso wenig geklärt werden wie der Umstand das beim AMD Pfad einfach auf einfache "Basics" zurückgegriffen wird. Dafür müsste man einen AMD als genuine Intel verifizieren. Aber das geht ja leider nicht.

Gerade im Memory Subsystem müsste der AMD punkten aber genau das Gegenteil passiert.

 

[Undertaker 1]

So in etwa meinte ich das auch, von außen kann man schwer sagen was da genau passiert - das trifft auch auf die Speicherergebnisse zu. Auf die sogar ganz besonders, da hier AMD seit dem A64 die andere Architektur hat als Intel und Via mit dem FSB - hier wird der falsche Pfad wohl in beiden Richtungen die deutlich schlechteren Ergebnisse liefern.

Übrigens: Das der Nano mit AMD-CPUID schneller ist als mit VIA-ID stützt die These, dass AMD hier nicht bewusst ausgebremst wird sondern der Nano einfach @def. kein bisschen optimal läuft. Die nähere Verwandschaft zu Intel-CPUs erklärt die damit besseren Ergebnisse.

 

[daysleeper83]

Man kanns auch anders sehen (spekulation)

2005 war SSE2 schon präsent was mit SSE3 war weiß ich momentan nicht

Dem Via Chip wird in seinem "Optimierungspfad" max SSE 1 vom C3 mitgegeben, was anderes wird beim K8 (welcher zu dieser Zeit schon SSE2 hatte) auch nicht verwendet während Intel bei seinem Pfad auf alle Instruktionen zurückgreifen kann.

 

[Undertaker 1]

Jep, dass erklärt schonmal warum der Via mit Intel-ID schneller ist als default. Da er aber auch mit AMD-ID etwas zulegt, werden sich die Optimierungen nicht nur auf SSE beziehen.

 

[che new]

Es gab doch Ende 2006 den 1.2.0 Patch für PCMark05, wurde da nicht etwas auf neue CPUs angepasst, z.B. Core2? Warum man bei AMD-CPUs die SSE2-Einheit nicht nutzt, gibts da ne Erklärung zu? Selbst SSE3 ist seit dem Venice im A64 implementiert.

Die wirkliche Leistung aller Non-Intel-CPUs wird so zumindest nicht wiedergegeben.

 

[Undertaker 1]

Nö, laut Changelog gabs keine Anpassung der Benchmarkroutinen, nur Bugfixes und aktualisierte Systeminfo-Datenbanken.

* Windows Vista enabled
* Fixed splash screen on Windows Vista
* Fixed WMP detection
* Fixed transparent windows issues
* Fixed looping issues with HDD tests
* Improved startup speed by optimizing the SystemInfo component
* Updated SystemInfo component with support for the latest CPU and graphics hardware
* Fixed all reported & reproduced issues

 

[daysleeper83]

Nochmal eine schöne Zusammenfassung mit weiterführenden Links

http://www.planet3dnow.de

 

[che new]

Erstaunlich finde ich das dann der Atom so gute Ergebnisse liefert.

Edit: Nach dem Artikeln nicht mehr

 

[mr.dude]

Übrigens: Das der Nano mit AMD-CPUID schneller ist als mit VIA-ID stützt die These, dass AMD hier nicht bewusst ausgebremst wird sondern der Nano einfach @def. kein bisschen optimal läuft. Die nähere Verwandschaft zu Intel-CPUs erklärt die damit besseren Ergebnisse.

Das würde es vielleicht, wenn die Unterschiede relativ konstant wären oder VIA noch vor AMD. ABER, zwischen VIA und AMD ist der Unterschied relativ gering, der Unterschied zu Intel relativ gross. Dh, das stützt deine These eher nicht. Es ist vermutlich wieder die alte Geschichte, dass für Intel CPUs erweiterte Befehlssätze genutzt werden, was für Nicht-Intel CPUs nicht zutrifft. Im besagten Test scheint es eine solche Diskrepanz eben auch zwischen VIA und AMD zu geben, die allerdings weniger gravierend ist. Normalerweise sind verschiedene cpuid Bits dafür zuständig, um entsprechende Features (MMX, SSE, 3dnow, etc) zu erkennen. Nicht jeder Compiler hält sich aber daran und nimmt als weiteres Entscheidungskriterium den Hersteller String, siehe ICC.
Interessant wären mal Sandra Tests.

 

[daysleeper83]

Mich würde es eher mal bei Cinebench10 interessieren wenn man den Nano als Intel ausgibt.

 

[DonGeilo]

Futuremark bevorzugt Intel-Prozessoren?

 

[[HOT]]

Den Verdacht hatte ich schon länger. Hier wurden viele Bibliotheken offenbar mit dem ICC compiliert. Der CPUID-Hack beweist genau das.

 

[Undertaker 1]

Wir wissen nicht, was die CPUID-abhängigen Optimierungen genau umfassen... Nochmal, wenn man AMD hätte ausbremsen wollen, der Nano mit AMD-ID nicht schneller geworden...

Eine simple Erklärungsmöglichkeit:

Der Nano nutzt @def nur SSE1.
Mit AMD-ID kommt SSE2 dazu, kleinere Vorteile.
Mit Intel-ID kommt SSE3 dazu, was hier z.T. große Zuwächse bringen kann.

Generell ist mir ein Benchmark wie der PC-Mark aber viel zu intransparent und praxisfern, hier gibt es genügend sinnvollere Alternativen an realen Programmen (Renderer, Encoder, Packer, ...), die zu einem viel besser die relevante Performance aufzeigen können und zum anderen jegliche Diskussion über Cheats überflüssig machen - hier zählt nämlich am Ende für den Anwender nur was rauskommt, und weniger wie es erreicht wird.

 

[Mondrial]

[...]hier zählt nämlich am Ende für den Anwender nur was rauskommt, und weniger wie es erreicht wird.

Und wie immer vergisst du bei deinen Ausführungen das es genau darum geht

Wichtig ist was dabei rauskommt, wenn aber Nicht-Intel-CPUs aufgrund veralteter bzw. nicht verwendeter Rechenpfade und Befehlssätze ausgebremst werden, kommt beim Anwender eben nicht das raus, was die CPU leisten könnte. Ganz simples Problem, welches keiner weiteren Ausführung bedarf...

 

[[HOT]]

Undertaker, es ist noch unbedingt davon auszugehen, dass das Absicht von FM war. Es könnte auch schlicht Schlamperei und Kostenoptimierung sein, um nicht verschiedene Codepassagen renovieren und neu kompilieren zu müssen. Es kommt aber auch darauf an, was man für Bibliotheken verwendet und von wem die kompiliert wurden. Ich sage auch nicht, dass AMD überall im Code Nachteile hat, das wird nicht der Fall sein, sonst wären die Ergebnisse noch schlechter. Ein solches Programm nutzt ja auch nen Haufen DLLs, die nicht unbedingt von FM sind und es gibt sicherlich auchnoch Kompilate aus der Zeit von FinalReality (das kennt heute keine Sau mehr, der Urvater aller 3DMarks).
Zudem glaube ich nicht, dass der ICC zum Einsatz kam, sondern dass Abfragen eingebaut wurden, die Optimierungen freischalten. Ansonsten würden VIA und AMD-CPUs gleich schlecht behandelt und nur Intel-CPUs vorgezogen.
Die Unterschiede zwischen VIA und AMD könnten auch von evtl. aber auch von AMDs MMX+ herrühren. Der erste PCMark wurde in einer Zeit in einer Zeit entwickelt, in der SSE rein Intel war und AMD einen Thunderbird vorweisen konnte, der nur 3DNow+ und MMX+ konnte. Grosse Teile davon werden sich in den neueren PC-Marks weitervererbt haben und das wird sich bis heute kaum geändert haben. Für die 3DMark gilt das analog natürlich.

 

[che new]

Winchester 3500+ und Venice 3500+ bringen die gleichen Ergebnisse in PCMark05, obwohl der Venice SSE3 besitzt: http://www.tomshardware.com/de/benc...s-von-amd-und-intel,testberichte-1289-85.html
Deutet schon mal daraufhin, dass generell kein SSE3 bei AMD-CPUs verwendet wird. Jetzt müsste man noch die Frage klären ob wenigstens SSE2 verwendet wird.
Es gibt doch glaube ich Boards die im BIOS erlauben SSE2/SSE3 zu deaktivieren oder? Wäre einen Bench-Versuch wert.