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

Status
Für weitere Antworten geschlossen.
daysleeper83 schrieb:
Könnte man nicht einen Intel über Virtualisierung emulieren ?
Zum Vergrößern anklicken....
Das geht sicherlich. Ich habe vor ein paar Tagen zB mal Super Pi mittels QEMU und ReactOS laufen lassen. CPUID hier anzupassen, dürfte weniger ein Problem sein. Die Frage ist nur, wie aussagekräftig das ist. Sämtliche Hardware, auch der Prozessor, wird eben nur emuliert bzw virtualisiert. Eine native Laufzeitumgebung ist einfach noch mal etwas anderes.
Aber mal schauen, eventuell gibt es doch eine Möglichkeit, den Hersteller String anzupassen. AMD hat scheinbar eine ganze Reihe undokumentierter cpuid Funktionen, die wohl den Entwicklern vorbehalten sein sollten. Central Brain Identifier konnte zB den CPU String temporär ändern. Auch wenn ich nicht weiss, ob das mit aktuellen CPUs noch funktioniert.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich dachte eher an VM Ware, man bräuchte ja nur uneingeschränkten Zugriff auf die MSR Register und schon könnte man das machen. Ich schau mal ob das geht.
 
daysleeper83 schrieb:
Könnte man nicht einen Intel über Virtualisierung emulieren ? Ansonsten ->



http://www.arium.com/products/ecmhdtice.html

Kann jemand so ein Ding besorgen :confused:.
Hinzugefügter Post:


Nein sondern ob der Intel Compiler den AMDs einen anderen SSE2 Code gibt als den Intels und dadurch das Ergebnis künstlich ausgebremst wird
Zum Vergrößern anklicken....

Nochmal, wie willst du damit eine Ausbremsung (unzulässig) von einer Optimierung (legitim) unterscheiden können? Ersteres haben wir nur eindeutig für den Fall, dass eine AMD-CPU mit dem Intel-Code schneller läuft, siehe deinen XS-Link. Das wäre dann auch für andere Anwendungen zu untersuchen.
 
Du hast schon gesehen das ich mich auf Hot bezogen hatte, der mit einem Nano dieses Thema untersuchen will? ;) Damit bekommt er nuneinmal nur heraus was dem Via besser schmeckt, nicht ob AMD-CPUs benachteiligt werden.
 
So VMWare läuft etc pp. Jetzt bräuchte man nur noch die zuständigen Register für die CPUID ....
Hinzugefügter Post:
Hmm VMWare reich die CPU nur weiter, da wird wohl nix gehen. Was gibts noch ? Bochs?
 
Zuletzt bearbeitet:
Undertaker 1 schrieb:
Du hast schon gesehen das ich mich auf Hot bezogen hatte, der mit einem Nano dieses Thema untersuchen will? ;) Damit bekommt er nuneinmal nur heraus was dem Via besser schmeckt, nicht ob AMD-CPUs benachteiligt werden.
Zum Vergrößern anklicken....
Du scheinst nicht zu verstehen, was er meint. Nochmal GAAAAANZ LAAAAANGSAM, damit auch du es verstehst.
Code: 
1. sage Nano, er sei "AuthenticAMD"
2. benchmarke
3. sage Nano, er sei "GenuineIntel"
4. benchmarke
5. vergleiche Ergebisse
Du verstehen? :rolleyes:

Damit lässt sich zwar noch nicht sagen, wie Cinebench, oder welche Anwendung auch immer, auf einem AMD Prozessor mit "GenuineIntel" läuft, ist hier aber auch nur nebensächlich. Man kann zumindest erstmal sagen, ob es grundsätzlich Unterschiede gibt.
 
Zuletzt bearbeitet:
Wie schwer drück ich mich denn aus... :rolleyes: Also nochmal, du benchst das ganze wie beschrieben und kommst auf 2 verschiedene Ergebnisse. Meinetwegen das höhere mit der Intel-ID. An welcher Stelle kannst du jetzt erkennen, ob a) eine Einbremsung über die AMD-ID vorliegt oder b) dem Nano schlicht die Intel-Optimierungen besser schmecken als die AMD-Optimierungen?
 
Wovon du sprichst, sind in erster Linie Mikrooptimierungen. Die werden nicht über cpuid zur Laufzeit gesteuert, sondern bereits beim Kompilieren festgelegt (mal abgesehen von VMs). Dh, da der Nano hardwaretechnisch gleich bleibt, bleibt auch das Laufzeitverhalten hier gleich. Mittels cpuid werden eher separate Routinen mit unterschiedlichen Befehlssätzen, Bibliotheksfunktionen oä gesteuert. Und dort kann man eigentlich recht gut abschätzen, wie die Unterschiede einzuordnen sind, siehe pcmark05. Wenn es kein künstliches Ausbremsen gäbe und nach deiner Theorie dem Nano Intel Code besser schmeckt, warum liegt er @default dann noch hinter "AuthenticAMD"? Und wenn ihm AMD Code besser schmeckt, warum liegt er mit "GenuineIntel" vor "AuthenticAMD"? Und wenn ihm beides gleich gut schmeckt, warum ist zwischen "AuthenticAMD" und "GenuineIntel" ein solcher Unterschied? Du siehst, das ist nichts als simple Logik. Und bei entsprechenden Voraussetzungen genauso auf andere Anwendungen übertragbar.
Es geht hier auch nicht um AMD vs Intel, auf das du die Thematik scheinbar immer reduzieren willst. :rolleyes: Es geht um "GenuineIntel" und Non-"GenuineIntel" Code.
 
Undertaker 1 schrieb:
Du hast schon gesehen das ich mich auf Hot bezogen hatte, der mit einem Nano dieses Thema untersuchen will? ;) Damit bekommt er nuneinmal nur heraus was dem Via besser schmeckt, nicht ob AMD-CPUs benachteiligt werden.
Zum Vergrößern anklicken....

Das hat mal so garnichts mit "besser schmeckt" zu tun. Es geht nur einzig und allein um die Veränderung der CPU-ID. Es geht nur darum herauszufinden, ob Intel-CPUs durch die CPU-ID bevorteilt werden, sonst garnichts. Ist eine VIA-CPU mit Intel-CPUID schneller als mit VIA-CPUID, ist hier auch von einer Bevorzugung der Intel-CPUID auszugehen. Optimierter Code schmeckt jeder CPU besser, da ja alle seit K6 bzw. PentiumPro im Prinzip nach dem gleichen Schema arbeiten (Decoder mit RISC-Backend).
 
Zuletzt bearbeitet:
Damit kannst du aber das nicht erklären

I just tried Intel C++ compiler version 10.1 with option /QxO as you suggested. It generates the following versions of code for common mathematical functions: SSE2, SSE3, SSE4.1 and non-Intel SSE2. It doesn't work on any CPU prior to SSE2. This is the only compiler option that makes it run reasonably on an AMD, but why are there two different SSE2 versions, one for Intel and one for AMD? When I hack the CPU-dispatcher and makes it believe that it is an Intel, it runs 50 - 100 % faster. This means that the Intel-SSE2 version is faster than the AMD-SSE2 version when running on an AMD processor!
Zum Vergrößern anklicken....

Alles spricht dafür, dass der AMD Code suobtimal ausgelegt ist. Der Intel Compiler ist ja auch nicht ohne Grund mit ein Gegenstand im Kartellrechtverfahren gegen Intel.
 
Und so müsste man es auch bei anderen Anwendungen untersuchen, dass sag ich doch die ganze Zeit :)
 
Dafür brauchst du den Source Code für alle gängigen Benchmarks, da man die CPUID wie bereits erwähnt bei AMD nicht einfach umschreiben kann. Bleiben nur noch Linux Benchmarks oder der Umweg über den Nano.
 
Und das der Weg über den Nano nichts aussagt, habe ich ja schon mehrfach erwähnt. Siehe auch meinen letzten Link, mit dem Nano kannst du Optimierungen nicht von Ausbremsungen unterscheiden.
 
"Allein das Verändern der Prozessor-Taktrate über den Multiplikator bei ansonsten identischen Prozessoren kann dazu führen, dass Code verändert werden muss, um optimale Performance zu erzielen."
 
Ja und weiter heißt es:

"Denn bei einer höheren Taktrate wird zwar der Cache, aber nicht der RAM schneller, und damit fällt die Penalty eines Cache-Miss höher aus."

Was hat das nun mit der CPU-ID zu tun und wo beweist es, was der Compiler für bestimmte CPUs nicht z.B. verschiedene Rechenpfade festlegt?
 
Warum sollte es verwerflich sein, wenn ein Programm für AMD und Intel verschiedene Rechenpfade zur Verfügung stellt? Solange der AMD-Pfad auf einer AMD-CPU der schnellste ist und umgekehrt, ist dies eine zulässige Optimierung.
 
Wie ausführlch soll ich denn noch werden???

Also, ein Programm besitzt verschiedene Rechenpfade. Absolut zulässig. Je nach CPUID wird der ein- oder andere ausgewählt. Ebenfalls kein Punkt zur Kritik. Voraussetzung: Nutze ich eine AMD-CPU, wäre der Intelpfad langsamer, nutze ich eine Intel-CPU, der von AMD. Nutze ich nun einen Via Nano, für den es keinen eigenen Pfad gibt, kann ich allein aus der Performance des Nano auf dem Intel- und dem AMD-Pfad nicht aufschlüsseln, ob dieser Unterschied durch eine etwaige bewusste Benachteiligung von AMD-CPUs bedingt ist oder schlicht durch den Fakt, dass der AMD-Pfad schlechter zur Architektur des Nano passt als der Intelpfad. Das letzteres möglich ist, sagt der obige Link.
 
Undertaker 1 schrieb:
Wie ausführlch soll ich denn noch werden???

Also, ein Programm besitzt verschiedene Rechenpfade. Absolut zulässig. Je nach CPUID wird der ein- oder andere ausgewählt. Ebenfalls kein Punkt zur Kritik. Voraussetzung: Nutze ich eine AMD-CPU, wäre der Intelpfad langsamer, nutze ich eine Intel-CPU, der von AMD. Nutze ich nun einen Via Nano, für den es keinen eigenen Pfad gibt, kann ich allein aus der Performance des Nano auf dem Intel- und dem AMD-Pfad nicht aufschlüsseln, ob dieser Unterschied durch eine etwaige bewusste Benachteiligung von AMD-CPUs bedingt ist oder schlicht durch den Fakt, dass der AMD-Pfad schlechter zur Architektur des Nano passt als der Intelpfad. Das letzteres möglich ist, sagt der obige Link.
Zum Vergrößern anklicken....

Der Skandal ist doch, daß es einen AMD-Pfad gibt, der langsamer rechnet, als wenn der AMD-Prozessor den Intel-Pfad benutzen würde. Die Auswahl wird natürlich automatisch getroffen, so daß es der Normalbenutzer nicht merkt. Der AMD-Prozessor wird damit bewußt langsamer laufen gelassen, als es nötig wäre. Der Zweck der Übung kann ja nur sein AMD zu diskreditieren, was ja auch sehr großflächig funktioniert hat. In einem anderen Forum habe ich es nur gewagt dazu aufzufordern sich in diese Thematik einzulesen und wurde mit einer Welle aggressiver Beschimpfungen bedacht (Gelesen wurde natürlich nicht).

I just tried Intel C++ compiler version 10.1 with option /QxO as you suggested. It generates the following versions of code for common mathematical functions: SSE2, SSE3, SSE4.1 and non-Intel SSE2. It doesn't work on any CPU prior to SSE2. This is the only compiler option that makes it run reasonably on an AMD, but why are there two different SSE2 versions, one for Intel and one for AMD? When I hack the CPU-dispatcher and makes it believe that it is an Intel, it runs 50 - 100 % faster. This means that the Intel-SSE2 version is faster than the AMD-SSE2 version when running on an AMD processor!
 
Zuletzt bearbeitet:
Undertaker 1 schrieb:
Und das der Weg über den Nano nichts aussagt, habe ich ja schon mehrfach erwähnt. Siehe auch meinen letzten Link, mit dem Nano kannst du Optimierungen nicht von Ausbremsungen unterscheiden.
Zum Vergrößern anklicken....

Das ist Quatsch. Ob man das jetzt mit einem Nano oder einer AMD-CPU testet macht keinen Unterschied. Die Optimierung ist klar zu sehen. Für gewöhnlich ist es sogar so, dass AMD-CPUs mit einem gepatchten Intel-Compiler deutlich schneller sind als mit M$s Standardcompiler. Ich sagte ja schon, dass "CPU-Optimierung" was anderes ist, als du darunter verstehst. Die CPUs, die heute auf dem Markt sind, sind keine echten x86er mehr, wo man durch die richtige Befehlsfolge noch einiges mehr rausholen konnte - die jetzigen CPUs sind eher sowas wie Universalgenies, um eben auch mit schlechtem Code umgehen zu können. Per Befehlsdecoder bleibt heutzutage nicht mehr viel übrig von x86-Befehlsoptimierung, da die CPU die Befehle selber in einen für die CPU eigenen Befehlssatz zerlegt und neu optimiert zuordnet. Da die CPUs heute ihre Befehlsfolge selber sortieren, das kümmert den Entwickler auch nicht mehr, Assembler schreiben bringts heute kaum noch. Optimierungen, die man für Intel-CPUs macht, kommen also auch allen anderen Typen genauso zugute, wenn sie denn dann funktionieren und bestehen meist eher in SSE-Spielereien, da das der einzige Weg ist, einer x86-CPU noch halbwegs direkt Befehle zu erteilen. Und genau da blockiert Intel und das ist einfach nicht in Ordnung. Auch eine schlichte CPU-ID-Abfrage im Code ist nicht in Ordnung, man muss eher die CAPs abfragen, also welche Features vorhanden sind. Die Abfrage des Markenstrings sollte es überhaupt nicht geben, da sie einfach keinen Sinn mehr machen, außer eben einen Konkurrenten zu benachteiligen. Intels Compiler ist sehr gut, aber eben nicht nur für Intel-CPUs, deswegen sperrt Intel andere CPU-Typen ja auch aus, sonst müsste man sowas ja garnicht praktizieren.
Bei der PC-Mark05 hab ich ja ne plausible Theorie: Viel Code stammt noch aus dem Urahn PC-Mark02 und dieser ist mit einem Compiler kompiliert worden, der bei AMD nur MMX+ erkennt und bei Intel SSE. VIA erkennt der garnicht, daher der Unterschied. Das würde auch genau zu den Abständen passen: SIMD bei FP nur bei Intel und geringe Int-SIMD-Vorteile für AMDs MMX+.
 
Zuletzt bearbeitet:
Genau das bezweifle ich. Die AMD-Architektur mit dem IMC mit dem Nano zu vergleichen ist doch ganz schön gewagt, wenn schon eine alleinige Taktänderung innerhalb einer Baureihe Optimierungsänderungen erfordern kann.
Ein ganz billiges Beispiel ist doch, wenn man versucht auf einer Core2 CPU eine Berechnung bzw. deren Daten soweit wie möglich im L2 Cache halten zu können, wärend es bei einem A64/Phenom mit IMC von Vorteil sein kann, sich hier nicht übermäßig einzuschränken und auch den Ram im größeren Umfang zu nutzen, da der Geschwindikeitsunterschied zwischen L2 und Ram geringer ist.
 
Zuletzt bearbeitet:
Der IMC bringt Vorteile bei der Speicherlatenz, sonst garnichts. Das bedeutet doch nur, dass AMD besser mit grossen Datenmengen umgehen kann, das ist aber nicht Gegenstand der Diskussion - hier geht es nicht um grosse Datenmengen. Natürlich kann man mit dem Nano nachweisen, dass hier Scheisse kompiliert wurde. Die CPU ist ähnlich, was anderes spielt keine Rolle. Ein Code, der mit einem anständigen Compiler kompiliert wurde, darf keinen, garkeinen Unterschied bei unterschiedlichen CPUID-Herstellerstrings machen. Ein PGI-Compiler, der auf SSE2 mit Vektorisierung compiliert, macht z.B. keinen Unterschied zwischen AMD und Intel-CPUs. Allerdings kann der PGI auch SSE4a und AMB, was dann schon wieder grosse Unterschiede macht, aber eben nur auf der Basis dieser Features und nicht auf Basis irgendwelcher Herstellerstrings.
 
Zuletzt bearbeitet:
Nochmal, wie erklärst du dir dann das z.B. schon eine simple Taktänderung eine abweichende Optimierung erfordern kann? Alles falsch was zdnet da schreibt?
 
Das im Artikel genannte Beispiel trifft nicht nur auf Intel-CPUs zu, falls dir das entgangen ist...
Die Zielsetzung bleibt die gleiche, egal um welche CPU es sich handelt.
 
Zuletzt bearbeitet:
Wenn schon ein simpler Taktunterschied solche Auswirkungen hat, wiegen architektonische Unterschiede noch vielfach schwerer, insofern will mir deine Argumentation nicht so ganz einleuchten.
 
Kann mir mal jemand das Freund-Feind Bild erklären? Ist Intel jetzt pöse oder die Benchmarkentwickler?^^
 
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