News Benachteiligung durch Intel-Compiler auf AMD-Systemen umgehen

Das Thema ist grundsätzlich bereits einige Jahre alt und auch bei uns im Forum hinreichend diskutiert, weshalb wir hier einfach mal auf die entsprechenden Threads und Meldungen verweisen:<ul><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=336249">Immer noch: Intel Compiler benachteiligt AMD CPUs [P3D Forum]</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1121692550">Kartellklage: Boykottiert der Intel-Compiler AMD-Chips?</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1217539570">Futuremark bevorzugt Intel-Prozessoren?</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1260976114">Amerikanische Kartellbehörde klagt Intel an</a></li></ul>Kurz und knapp zusammengefasst: Intel pflegt einen eigenen Compiler und das mit hohem finanziellen Aufwand. Nun kann man darüber streiten, ob es "fair" ist - sofern dieser Begriff in einer Konkurrenz-Situation auf dem freien Markt überhaupt anwendbar ist - dass Intel dafür sorgt, dass die Optimierungen des Intel-Compilers hauptsächlich Intel-Prozessoren zu Gute kommen und AMD-Prozessoren - obwohl sie eventuell von den Optimierungen auch profitieren würden - nicht.

Bereits vor 2 Jahren haben wir <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1217539570">ausführlich berichtet</A>, welchen Unterschied es in Sachen Leistung machen kann, wenn Hersteller spezifische Optimierungen genutzt werden oder auch nicht. Damals wurde der VIA Nano Prozessor als Vergleich herangezogen, der es ermöglicht die Vendor CPUID des VIA-Prozessors zu ändern und dem Programm - in diesem Fall dem Futuremark PCMark2005 - eine Intel-CPU vorzugaukeln. Daraufhin stieg der Wert im Memory-Benchmarks von 1845 (CPUID = VIA) auf 2721 (CPUID = Intel) Punkte.

Bei einem AMD-Prozessor dagegen ist es nicht so einfach die sichtbare Vendor ID für die Programme zu manipulieren. Einzige Möglichkeit hier: Virtualisierung. Richtet man über VMWare ein virtualisiertes System ein, ist es sehr wohl möglich, dem Gastsystem eine andere CPUID zu verpassen, als das Hostsystem tatsächlich besitzt. In <a href="http://www.agner.org/optimize/blog/read.php?i=49#118" target="_blank">Agners CPU-Blog</A> wird beschrieben, wie das funktioniert:<blockquote><i>By analogy to Andrew's code, I assume that you can make an AMD processor spoof to be "GenuineIntel" with these lines:

cpuid.0.ebx="0111:0101:0110:1110:0110:0101:0100:0111"
cpuid.0.edx="0100:1001:0110:0101:0110:1110:0110:1001"
epuid.0.ecx="0110:1100:0110:0101:0111:0100:0110:1110"

The Intel software also checks the family number, which should be set to 6:

cpuid.1.eax="0000:0000:0000:0001:0000:0110:0111:0001"</i></blockquote>Anschließend sieht die Software innerhalb des Gastsystems einen Intel-Prozessor, selbst wenn das Host-System eine AMD-CPU besitzt. Ist die performance-kritische Software, die eingesetzt werden soll, mit einem Intel-Compiler übersetzt, sollte das die Leistung erheblich steigern. Voraussetzung ist allerdings, dass die eingesetzte Software sämtliche Flags korrekt abfragt, denn nicht immer beherrschen aktuelle AMD-Prozessoren auch sämtliche Befehle der vergleichbaren Intel-Prozessoren. Beispiel: SSSE3, das bisher kein AMD-Prozessor beherrscht, oder spezielle SMT SIMD-Befehle älterer Intel-Prozessoren, die auf AMD-Prozessoren in Ermangelung von SMT nicht implementiert waren. Fragt die Software sämtliche relevanten Flags korrekt ab, ist das kein Problem. Ist die Software jedoch schlampig programmiert und "denkt sich", <i>"ah, Intel Prozessor, dann muss dies und jenes ja unterstützt werden"</i>, stürzt das Programm bei der Anwendung dieses Virtualisierungstricks kurzerhand ab.

jetzt sollte AMD nur noch nen Patch rausbringen, wie seinerzeit Cyrix [via Diskette] für seine CPUs...
Ruck zuck [via CD aufgespielt] funzt das ganze und AMD holt seine ~30% Compilerlücke auf.

...Leider wird das nicht so einfach sein und ob AMD dazu Lust hat...nun, AMD hätte dies wohl längst getan oder?

Müsste dann aber doch irgendwie "AMD" in den Programmen stehen, sonst wird das AMD gleich zwei mal nicht machen...und damit würde es noch schwieriger

S.I. schrieb:

...Leider wird das nicht so einfach sein und ob AMD dazu Lust hat...nun, AMD hätte dies wohl längst getan oder?

Zum Vergrößern anklicken....

Wie gesagt: bei AMD-Prozessoren lässt sich die CPUID nicht per Software verändern! Daher können solche Tricks wie CPUID-Update per Diskette etc. nicht funktionieren!

Das funktioniert nur per Virtualisierung!

Kann das denn in der Praxis auch was bringen?! Also in dem Fall, dass man sowieso mehrere VMs laufen lässt, kann ich mir das noch vorstellen.
Aber was ist mit dem Fall, dass ich eigentlich ein Programm "normal" ausführen möchte. Also ich habe dann eine einzelne VM die meinen realen Rechner "ersetzt". Kann man dann auch Geschwindigkeitsvorteile erzielen (Programm direkt ausgeführt vs. Programm in VM ausgeführt)?

Nero24 schrieb:

, "ah, Intel Prozessor, dann muss dies und jenes ja unterstützt werden", stürzt das Programm bei der Anwendung dieses Virtualisierungstricks kurzerhand ab.

Zum Vergrößern anklicken....

Naja, gibt ja auch alte Intel CPUs, die kein SSE4 konnten, das sollte dann ok sein.

Notfalls könnte man höchstens noch das "Model" auf 14 setzen, das waren die ersten Core CPUs mit maximal SSE3.

ciao

Alex

LoRDxRaVeN schrieb:

Kann das denn in der Praxis auch was bringen?! Also in dem Fall, dass man sowieso mehrere VMs laufen lässt, kann ich mir das noch vorstellen.
Aber was ist mit dem Fall, dass ich eigentlich ein Programm "normal" ausführen möchte. Also ich habe dann eine einzelne VM die meinen realen Rechner "ersetzt". Kann man dann auch Geschwindigkeitsvorteile erzielen (Programm direkt ausgeführt vs. Programm in VM ausgeführt)?

Zum Vergrößern anklicken....

Das kommt auf das Programm an! Von den ganzen Benchmarks mal abgesehen, die produktiv ja nichts leisten, könnte ich mir vorstellen, dass die ein oder andere BOINC-Anwendung mit optimierten Clients davon profitieren könnte, oder wenn Du viele Audio-Streams umwandelst und dafür einen der weit verbreiteten LAME-Encoder verwendest, die mit dem "ICL" übersetzt wurden; dann lohnt es sich, vorher eine VMWare-Sitzung mit manipulierten CPUIDs zu starten, wenn sich die Encoding-Zeit von 3 auf 2 Stunden verkürzt oder die BOINC-Anwendung statt 1 Stunde plötzlich nur noch 40 Minuten je Kern benötigt. Ansonsten für Klick-und-Fertig Anwendungen natürlich nicht!

@Nero hast Du vor zu testen ?
Cinebench wäre wohl als erstes interessant ^^

Angeblich ja auch AMD optimiert, aber Kontrolle ist besser

Opteron schrieb:

@Nero hast Du vor zu testen ?

Zum Vergrößern anklicken....

Nein, dafür habe ich keine Zeit - leider. Aber wenn jemand mit dem nötigen Background-Wissen mag - speziell aus der DC-Abteilung - bitte gerne

AMD hat leider noch nie die Entwickler/Workstations als lohnende Zielgruppe verstanden. Wie sehr aber Produkte nicht durch den Consumer sondern durch die Faulheit bzw. den Zeitdruck von uns Entwicklern beeinflusst werden, scheint kaum einem bewusst zu sein.

Sicher bin ich in der Lage trotz künstlicher Compilerbenachteiligungen eine Software für AMD zu optimieren. Aber für ein paar wenige hundert Euro in der einmaligen Anschaffung meiner Hard/Software spar ich mir mit Intel Stunden bzw. Tage in der Projektplanung/-durchführung ganz ohne auch nur an Optimierung zu denken. Unser Nachwuchs hat meist null Ahnung mehr was überhaupt noch eine Compilerflag ist und kümmert sich einen Scheiß um Laufzeitkomplexitäten. Intel hatte schon früh erkannt, wenn man dem Entwickler Arbeit/Zeit durch Compiler, Codecs oder Hardware abnimmt kann man ihn und all seine Kunden auch locker in Abhängigkeiten zwingen ohne das man es Intel ankreidet.
AMD denkt scheinbar nur an den Consumermarkt und glaubt dieser würde dann die Entwicklung lenken ... Fehlanzeige.

yourgreatestfear schrieb:

AMD denkt scheinbar nur an den Consumermarkt und glaubt dieser würde dann die Entwicklung lenken ... Fehlanzeige.

Zum Vergrößern anklicken....

Na ne, vergess bitte nicht den AMD Compiler, der ist für Linux = Servermarkt gedacht.
Aufgrunddessen waren die Istanbul 6Kern Spec Benches auch plötzlich so gut, da er dabei erstmals Verwendung fand.

Aber unter Windows gibts leider noch nichts.

ciao

Alex

Opteron schrieb:

Na ne, vergess bitte nicht den AMD Compiler, der ist für Linux = Servermarkt gedacht.
Aufgrunddessen waren die Istanbul 6Kern Spec Benches auch plötzlich so gut, da er dabei erstmals Verwendung fand.

Aber unter Windows gibts leider noch nichts.

ciao

Alex

Zum Vergrößern anklicken....

Richtig - NOCH gibts kein Open64-Windows-Compiler aber AMD arbeitet daran !

Es stand doch sogar in der letzten DevMail von AMD, dass der Windowssupport kommt ... ist aber auch erforderlich, wenn man die Umfragewerte ( http://developer.amd.com/cpu/open64/Pages/default.aspx ) betrachtet

Der AMD-Compiler wird ja selbst von AMD noch nicht eingesetzt für leistungsrelevante Arbeiten.
Beispiel?
ATI Stream Software Development Kit (SDK) v2.2
Supported Compilers:

Microsoft® Windows®
Intel® C Compiler (ICC) 11.x
Microsoft® Visual Studio® (MSVS) 2010 Professional Edition
Microsoft® Visual Studio® (MSVS) 2008 Professional Edition
Minimalist GNU for Windows (MinGW) [GCC 4.4]

Linux®
GNU Compiler Collection (GCC) 4.1 or later
Intel® C Compiler (ICC) 11.x

Er ist ein zaghafter Schritt in die richtige Richtung aber noch lange nicht fertig um einem Intelcompiler paroli zu bieten. Was weniger an Optimierungen liegt, sondern vielmehr am Umfang des Pakets. Plattformen, die gebotenen Libraries und derren Funktionalität bis in zu Schnittstellen in typischen Umgebungen. Ich denk da aus eigener Erfahrung heraus nur an den Vergleich der Intel MKL mit der ACML, aber das Bild gilt generell für die meisten Entwicklerprodukte von AMD.
Den Umfang plattformübergreifend aufzuholen ist ein Brocken an dem AMD finanziell und zeitlich lange zu kauen hat. Zudem scheint Intel auch immer omnipräsent zu sein auf Messen und Entwicklertagungen. Von AMD wollt mir noch keiner den Arsch abwischen .

Naja und dem GCC unterstützen sie ja IMO auch mit Patches zur Optimierung. Dieser ist aber leider auch nur für Unix/Linux verfügbar.

Weiß einer wie es mit der Fairness des MS Visual C++ (und denen der anderen Sprachen) Compilers aussieht?

AMD hatte früher auch öfter mal div. Software gepatcht, oder gar tw. mit entwickelt, um sie an die AMD-Hardware optimal anzupassen. zB. bei Quake2 den Software 3dnow! Renderer, der dann sogar ohne 3D-Grafikkarte auf einem K6-2 ausreichend flotte Bildraten renderte.
Später gab es auch eigene optimierte 64-Bit Software (64-Bit Software ist ja auch wegen mehr Registern bis zo 20% schneller), wie Farcry, oder Unreal Tournament, um die Vorteile zu zeigen.
Hier muss AMD also wohl weiterhin aktiv dahinter sein, Intel wird dem Konkurrenten diese Arbeit sicher nicht abnehmen. Eher noch durch div. eher wenig nützliche Befehlssatzerweiterungen noch weiter Knüppel zwischen die Beine werfen.

yourgreatestfear schrieb:

Der AMD-Compiler wird ja selbst von AMD noch nicht eingesetzt für leistungsrelevante Arbeiten.
Beispiel?
ATI Stream Software Development Kit (SDK) v2.2
Supported Compilers:
..

Linux®
GNU Compiler Collection (GCC) 4.1 or later
Intel® C Compiler (ICC) 11.x

Zum Vergrößern anklicken....

Und was ist der Open64 Compiler von AMD ? Richtig ein Abkömmling der GCC 4.2 daher wird er Open64 wenigsten (derzeit) unter Linux unterstützt.

Auch arbeitet AMD sehr eng mit Microsoft zusammen, damit der MSCC besser wird

Klingt super, bis der Entwickler sich dann mit nicht unterstützten GCC Extensions auseinandersetzen muss (siehe Doku des Open64). Womit wir wieder beim eingeschränkten Umfang der AMDentwicklungen sind.
AMD verzichtet nicht ohne Grund auf die Erwähnung des eigenen Compilers in der Supportlist des SDK. Die wissen doch selbst, dass ihr Devsupport noch in den Anfängen steckt. Sowas brauch Zeit und es nimmt ihnen doch auch keiner übel. Eine echte Alternative ist es nur für ganz wenige derzeit.

Crashtest schrieb:

Und was ist der Open64 Compiler von AMD ? Richtig ein Abkömmling der GCC 4.2

Zum Vergrößern anklicken....

Öh nö, der AMD Compiler basiert auf dem Open64 compiler, aber mit GCC hat der Open64 Compiler die nichts am Hut.
Das Eizige war mal, dass sie das GCC Front End nutzten, aber sonst ist da alles anders.

yourgreatestfear schrieb:

Klingt super, bis der Entwickler sich dann mit nicht unterstützten GCC Extensions auseinandersetzen muss (siehe Doku des Open64). Womit wir wieder beim eingeschränkten Umfang der AMDentwicklungen sind.

Zum Vergrößern anklicken....

Naja March = Orochi (oder wie das heißt) und fertig ^^

ciao

Ale

Opteron schrieb:

Das Eizige war mal, dass sie das GCC Front End nutzten, aber sonst ist da alles anders.

Zum Vergrößern anklicken....

Das ist noch immer so, aber auch egal. Eine Fork des GCC isses nicht, sondern da wurde ein eigenes Brot gebacken. Punkt bleibt, dass es für AMD noch 'work in Progress' ist und der Open64 noch eine Weile in der Branche keine Rolle spielen wird. Hoffen wir mal nicht allzulang.

Opteron schrieb:

Naja March = Orochi (oder wie das heißt) und fertig ^^

Zum Vergrößern anklicken....

HÄ

PS: AMD ist gut beraten einfach Intel vorzugaukeln und parallel ihre DEVtools zur Marktreife zu bringen, die Arbeit die nötig wäre durch Eigenleistung in den fremden DEVtools aufzuholen ist enorm.

yourgreatestfear schrieb:

HÄ

Zum Vergrößern anklicken....

Sorry schlampig gelesen und Extensions mit Kommandozeilenparameter gleichgesetzt ^^

Nero24 schrieb:

...
Einzige Möglichkeit hier: Virtualisierung. Richtet man über VMWare ein virtualisiertes System ein, ist es sehr wohl möglich, dem Gastsystem eine andere CPUID zu verpassen, als das Hostsystem tatsächlich besitzt. In Agners CPU-Blog wird beschrieben, wie das funktioniert:<blockquote><i>By analogy to Andrew's code, I assume that you can make an AMD processor spoof to be "GenuineIntel" with these lines:

cpuid.0.ebx="0111:0101:0110:1110:0110:0101:0100:0111"
cpuid.0.edx="0100:1001:0110:0101:0110:1110:0110:1001"
epuid.0.ecx="0110:1100:0110:0101:0111:0100:0110:1110"

The Intel software also checks the family number, which should be set to 6:

cpuid.1.eax="0000:0000:0000:0001:0000:0110:0111:0001"</i></blockquote>

Zum Vergrößern anklicken....

Das geht mit KVM entschieden einfacher:
kvm -cpu core2duo,vendor=GenuineIntel ...
Für KVM braucht man natürlich Linux als Host, aber als Gast läuft Windows ganz prima. Und mit Nested Paging (ab Phenom bzw. den entsprechenden Opterons) ist die virtuelle Performance auch sehr gut.
Man kann über MSRs übrigens auch nativ (ohne Virtualisierung) die Feature-Bits, die per CPUID angezeigt werden, verändern (MSRC001_1004, Fam10h BKDG, Abs. 3.13), aber das erstreckt sich leider nicht auf die Vendor-ID und die Family/Model/Stepping Bits.

Nero24 schrieb:

Wie gesagt: bei AMD-Prozessoren lässt sich die CPUID nicht per Software verändern! Daher können solche Tricks wie CPUID-Update per Diskette etc. nicht funktionieren!

Das funktioniert nur per Virtualisierung!

Zum Vergrößern anklicken....

Dann sollte man mal bei einem kommenden Themenabend, sofern AMD dies dann auch wert ist zu erscheinen, mal erwähnen und diesbezüglich eine Änderung erwirken. Kann ja nicht so schwer sein, wenn das bei Cyrix auch möglich war. Es wird ja eh schon alles mögliche Manipuliert, verändert, freigeschaltet dann hätte AMD keinen Grund weiter rumzujammern und der Kunde entscheidet selbst ob er das Feature dann nutzen möchte oder nicht.

Vielleicht ist ja jedem Crack hier klar, wie man VMware obige Zahlen unterjubelt, im originalen Blog-Eintrag wird allerdings auf einen weiteren Eintrag verwiesen (der von Andrew), wo drin steht, dass man in der .vmx rumpfuschen muss. Für weniger-VMware-erfahrene Leute (wie mich), wäre das eventuell noch relevant.

Bei mir klappt es übrigens nicht (ich sag ja: unerfahren), weder Windows noch CPU-Z zeigen mir nen Intel als CPU an. Dafür hab ich aber ne AMD-CPU auf nem Intel-Baord am Laufen

Nero24 schrieb:

Beispiel: SSSE3, das bisher kein AMD-Prozessor beherrscht

Zum Vergrößern anklicken....

Was ist denn da los? Ich dachte das konnten selbst schon olle A64 ab E-Stepping oder ist das irgendwie im Zusammenhang mit Virtualisierung zu sehen?

LinuS schrieb:

Was ist denn da los? Ich dachte das konnten selbst schon olle A64 ab E-Stepping oder ist das irgendwie im Zusammenhang mit Virtualisierung zu sehen?

Zum Vergrößern anklicken....

die K8 im E Stepping konnten (neu) SSE3 aber nicht SSSE3 !

Dies ist neben SSE4.1, Teilen von 4.2 sowie AVX, XOP, FMA4, LWP und einigen anderen Dingen erst für Bulldozer (irgendwann in 2011) geplant

Das ganze ist ja ne nette sache, aber mehr hypothetischer Natur...warum?

Weil 95% der (für die masse relevante) Software mit einem Microsoft-Compiler (VS6, 2001, 2003, 2005, 2008 oder 2010) compiliert sind.

Was u.a. auch daran liegt das es die MS-Compiler als Express-Version für lau gibt (und der Intel Compiler richtig Kohle kostet).

Im Prinzip gibt es nur sehr wenige und meist dann auch sehr spezielle SW die mit dem Intel-Compiler compiliert wurden...häufig ist das nicht mal SW für den Markt, sondern rein interne SW.

Ihr werdet eher GCC-Compilate als Intel-Compilate unter Windows antreffen.