AMD wird benachteiligt! Manipulierte Intel-Compiler & gefälschte Benchmarks

[Mr T]

Von Intel zu verlangen, den eigens entwickelten Compiler auch für Konkurrenzprodukte zu optimieren, dünkt mich etwas vermessen. Auch die Entwickler von Anwendungssoftware dürften - selbst ohne Bestechungsgelder von Intel - kaum so programmieren, dass Core2 Prozessoren möglichst durch den Flaschenhals FSB gebremst werden, nur damit AMD Prozzis besser dastehen.

Eigentlich sollte es doch ganz einfach sein.

AMD lizenziert x86 von Intel -> AMD Prozessoren laufen auf von x86 Compilern kompiliertem Binaries.
AMD lizenziert SSE von Intel -> und auch daraus sollte folgen, das entsprechende Compiler für teures Geld/Abkommen lizenzierte Techniken nutzen.

entweder hat hier AMD bei den Patenaustauschabkommen geschlafen und es verpasst die Texte wasserdicht zu formulieren, oder Intel begeht hier Vertragsbruch. In der vorliegenden Lage ist AMD wohl als Konkurrent anzusehen sondern als Kunde, der entsprechende Technik einkauft. Was würden Fahrgäste der Bahn wohl sagen, wenn sie zwar die Fahrkarte bezahlen, aber der Zug dann die Tür nicht öffnet?

 

[stefanRTR]

Also hab mir gerade mal die Doku vom Intel Compiler durchgelesen und seit Version 11.x gelten die SSE Optimierungen auch für nicht Intel CPU's

arch

Tells the compiler to generate optimized code specialized for the processor that executes your program.
IDE Equivalent
Windows: Code Generation > Enable Enhanced Instruction Set
Linux: None
Mac OS X: None
Architectures
IA-32, Intel® 64 architectures
Syntax
Linux and Mac OS X:
None
Windows:
/archrocessor
Arguments
processor
Is the processor type. Possible values are:
IA32
Generates code that will run on any Pentium or later processor. Disables any default extended instruction settings, and any previously set extended instruction settings. This value is only available on IA-32 architecture.
SSE
This is the same as specifying IA32.
SSE2
Generates code for Intel® Streaming SIMD Extensions 2 (Intel® SSE2).
SSE3
Generates code for Intel® Streaming SIMD Extensions 3 (Intel® SSE3).
SSSE3
Generates code for Intel® Supplemental Streaming SIMD Extensions 3 (Intel® SSSE3).
SSE4.1
Generates code for Intel® Streaming SIMD Extensions 4 Vectorizing Compiler and Media Accelerators.
Default
SSE2
The compiler generates code for Intel® Streaming SIMD Extensions 2 (Intel® SSE2).
Description
This option tells the compiler to generate optimized code specialized for the processor that executes your program.
Code generated with the values IA32, SSE, SSE2, or SSE3 should execute on any compatible non-Intel processor with support for the corresponding instruction set.
Options /arch and /Qx are mutually exclusive. If both are specified, the compiler uses the last one specified and generates a warning.

 

[Phantomias88]

In der vorliegenden Lage ist AMD wohl nicht als Konkurrent anzusehen sondern als Kunde, der entsprechende Technik einkauft.

Nehalem is essentially basic Intel Core 2 microarchitecture with some important bells and whistles, many of which, it must be noted, are already present in equivalent form in AMD’s Phenom microarchitecture.

http://channel.hexus.net/content/item.php?item=12306

Beziehst du dich bei "Technik" auf die Architektur?

MfG

 

[PitGST]

*Beiträge entfernt*

 

[Opteron]

@stefanRTR:
Das mit dem QxO hatte ich schon vor ein paar Seiten erwähnt, gibts halt noch nicht so lange und die Klageschrift ist schon etwas älter.

Die 11er Instruktionen klingen schon mal ganz gut. So wie das ausschaut, ist das aber technisch nichts anderes als QxO, AMD CPUs werden mit dem gepatchen Intel Compilat weiterhin schneller laufen, aber für die FTC könnte es reichen.

Bemängeln könnte man jetzt nur noch die fehlende Zukunftssicherheit. Für die Erweiterungen ab SSE4 gibts keine non-intel Parameter. Wenn jetzt später in 2011 die Bulldozerchips mit SE41/42 und AES kommen, wird das wieder nicht erkannt / genutzt werden, obwohl es ja nachwievor Flags gibt.
Schon früher wird wohl VIAs Nano in die SSE4 Röhre schauen ... die sollten mal mitklagen ^^

Fazit: Schon mal besser als früher, eventuell reichts. Mehr könnte man nur verlangen, wenn AMD nachweisen könnte, dass die spezifischen Intel Optimierungen nichts mit der Architektur zu tun haben, sondern 08/15 Software Optimierungen wären.

Das könnte man zumindest vermuten, wenn man sieht, wie gut die Core Generation CPUs mit den vermeintlichen Prescott Optimierungen rechnen. Da waren wohl kaum übermäßig viel Netburst Optimierungen eingebaut ...

Hier noch ein link fürs 11er pdf:
http://cache-www.intel.com/cd/00/00/22/23/222300_222300.pdf

Auffällig ist, dass AMD explizit erwähnt wird, bisher wurde immer nur von non-intel gesprochen ;-)

Frohes Fest

Alex

 

[KlausW]

naja AMD wird wohl wegen dem Kürzlichen Vergleich nix derartiges tunw enn dann muss sich VIA dahinterklemmen und denen wird das geld dazu fehlen

 

[Opteron]

VIA ist ein kleines Rädchen im großen FormosaPlastic Verbund. Die haben genug Geld, ohne den wären sie vermutlich eh schon pleite ^^

Aber egal, bei AMD hast Du wohl recht. Ich warte mal auf die Compilerversion 11.2 oder 12, mal schauen, ob sich da signifikant etwas geändert hat.
AVX wird z.Zt. z.B. auch nur für Intel CPUs freigeschalten, auf das wird AMD pochen wollen.

 

[Undertaker 1]

Es bleibt dabei, eine solche Seite gab es nicht und unter realen Bedingungen ist dieser Bug nie aufgetreten...

AMD hat mal veröffentlich, unter welchen Bedingungen der Bug reproduzierbar wäre:

http://ht4u.net/news/1575_amd_nennt...elchen_sich_der_tlb-bug_reproduzieren_laesst/

Bei SPEC unter Vista x64 haben wir natürlich einen höchst kritischen Fall, der von vielen Reviews aufgedeckt worden wäre - hier musste man also handeln.

 

[[HOT]]

Seit dem Intel C++ Compiler 10.1 gib es zumindest diese Flag

Also hab mir gerade mal die Doku vom Intel Compiler durchgelesen und seit Version 11.x gelten die SSE Optimierungen auch für nicht Intel CPU's

Damit wird es aber noch bunter. Die "Optimierungen" für die Gegenseite sind damit nämlich nicht etwa weg, sondern gehen in eine neue Runde und wurden besser versteckt. Der Compiler macht nach wie vor eine Unterscheidung nach CPUID, das kann man mit VIA-CPUs nachweisen, weil sich dort die CPUID ändern lässt. Intel begründet die "Optimierung" damit, dass sie auf anderen CPUs nicht ordentlich laufen und bietet einen "Kompatibilitätsmodus" für nicht-Intel-CPUs an, was aber nach wie vor Schwachsinn ist, denn wird eine Spec unterstützt, dann voll, egal ob von AMD, VIA oder Intel. Eine Einteilung nach CPUID ist und bleibt Marktmanipulation. Das entlavt den Compiler aber als Machtinstument jetzt endgültig. Die FTC wird das genausowenig akzeptieren, wie die Compiler davor, denn die Nachweisbarkeit ist mit diesem "Verstecken" nicht vom Tisch, sondern immernoch problemlos möglich.

@stefanRTR:
[...]
Bemängeln könnte man jetzt nur noch die fehlende Zukunftssicherheit. Für die Erweiterungen ab SSE4 gibts keine non-intel Parameter. Wenn jetzt später in 2011 die Bulldozerchips mit SE41/42 und AES kommen, wird das wieder nicht erkannt / genutzt werden, obwohl es ja nachwievor Flags gibt.
Schon früher wird wohl VIAs Nano in die SSE4 Röhre schauen ... die sollten mal mitklagen ^^[...]

Formosa wird klagen, sobald die FTC entschieden hat. Und hier gab es noch keinen Ausgleich wie zwischen AMD und Intel. Das wird ebenfalls noch teuer für Intel. Das Ganze ist ja Kartellrecht. VIA/Formosa hat in dem Verfahren genausowenig was zu suchen wie AMD.

 

[temnozor]

Intel begründet die "Optimierung" damit, dass sie auf anderen CPUs nicht ordentlich laufen und bietet einen "Kompatibilitätsmodus" für nicht-Intel-CPUs an, was aber nach wie vor Schwachsinn ist, denn wird eine Spec unterstützt, dann voll, egal ob von AMD, VIA oder Intel. Eine Einteilung nach CPUID ist und bleibt Marktmanipulation. Das entlavt den Compiler aber als Machtinstument jetzt endgültig. Die FTC wird das genausowenig akzeptieren, wie die Compiler davor, denn die Nachweisbarkeit ist mit diesem "Verstecken" nicht vom Tisch, sondern immernoch problemlos möglich.

Es geht hier aber nicht darum das CPUs einen bestimmten Befehlssatz unterstützen sondern um Optimierungen. Jeder der mal Compilerbau an der Uni gehört hat weiß das der Bereich Optimierungen schwarze Kunst ist.
Einfach nur einen Compiler kann dir jeder 6. Semester schreiben.

 

[[HOT]]

Die Optimierung wird aber durch Erkennen der CPUID an und abgeschaltet. Es geht nicht um Optimierungen als solche, sondern um den politischen Umgang damit. Niemand würde etwas sagen, wenn der Compiler die Flags der CPU auslesen würde und dementsprechend die Features freigeben würde, also die AMD CPUs mit den Intel-Optimierungen "leben müssten". Das ist aber nicht der Fall, da liegt das Problem. Intel sperrt über die CPUID Optimierungen für Prozessoren von anderen Herstellern. Das ist im Prinzip nichts anderes wie SSE garnicht anzubieten. Intel kann sich nur besser rechtfertigen dafür.

 

[stefanRTR]

Die Optimierung wird aber durch Erkennen der CPUID an und abgeschaltet. Es geht nicht um Optimierungen als solche, sondern um den politischen Umgang damit. Niemand würde etwas sagen, wenn der Compiler die Flags der CPU auslesen würde und dementsprechend die Features freigeben würde, also die AMD CPUs mit den Intel-Optimierungen "leben müssten". Das ist aber nicht der Fall, da liegt das Problem. Intel sperrt über die CPUID Optimierungen für Prozessoren von anderen Herstellern. Das ist im Prinzip nichts anderes wie SSE garnicht anzubieten. Intel kann sich nur besser rechtfertigen dafür.

Ich denke du hast die beschreibung der arch flag nicht ganz verstanden.
wenn man /arch:SSE3 angibt gilt SSE3 für alle CPU's egal ob Intel oder sonstwas.
Gibt man die arch flag nicht an wird der Code mit SSE2 compiliert und das auch für alle Cpu's.

Es gibt da auch noch einige andere flags z.b. bei /m gilt das gleiche wie bei arch.

 

[[HOT]]

Ich glaube dass ich das sehr wohl verstanden hab . Es wird jetzt zwar SSE voll unterstützt (niemals bezweifelt), trotzdem erhalten CPUs in diesem "SSE-Kompatibilitätsmode" nicht denselben Code zum Abarbeiten wie Intel-CPUs. Ich glaube, das hast du missverstanden . Das Flag dürfte überhaupt nicht nötig sein.

 

[stefanRTR]

Doch wenn man arch oder m nimmt ist der Code gleich für alle CPU's.

Es gibt dann noch QX in verschiedenen varianten die sind aber speziell nur für Intel Cpus und damit wird der Code für Intel optimiert. Soweit ich weiß läuft das Programm dann nicht auf einem AMD oder einem Intel wenn z.B. für SSE4.2 Optimiert wurde und die CPU das nicht kann.
Man kann aber die Flags kombinieren z.B. /arch:SSE3 /qx:SSE42 dann wird wenn das Programm auf einen Intel mit SSE4.2 läuft der schnellere Code genutzt für alle anderen der andere.

Also braucht man nicht wie du sagst ein extra flag für Amd sondern für die Intel Optimierungen.

 

[Opteron]

Neuer Agner Blog Eintrag, größtenteils nur eine Zusammenfassung:

http://www.agner.org/optimize/blog/read.php?i=25

Guten Rutsch

Alex