intel specifieke compiler geeft athlonFX zelfde perf. boost?

[Puppetmaster]

weet niet of het topic hier op zn plaats is maar het gaat over een interessant stukje wat ik net las op Hardocp:
het is engels omdat ik geen zin had het te vertalen, wel een selectieve copy-paste

As part of my study of Operating Systems and embedded systems, one of
the things I've been looking at is compilers. I'm interested in
analyzing how different compilers optimize code for different
platforms. As part of this comparison, I was looking at the Intel
Compiler and how it optimizes code.

First I compiled and ran spec with the
"generic x86 flag" (-QxW), which compiles code to run on any x86
processor. After running the generic version, I recompiled and ran
spec with the "Intel-specific flag" (-QxN) to see what kind of
difference that would make. For most benchmarks, there was not very
much change, but for 181.mcf, there was a win of almost 22%

I tried running the same binary on an AMD FX51. First I ran the "generic x86" binaries on the FX51, and then tried to run the "Intel-only" binaries. The Intel-specific ones printed out an error message saying that the processor was not
supported and exited.

I started mucking around with a dissassembly of the Intel-specific
binary and found one particular call (proc_init_N) that appeared to be
performing this check. As far as I can tell, this call is supposed to
verify that the CPU supports SSE and SSE2 and it checks the CPUID to
ensure that its an Intel processor. I wrote a quick utility which I
call iccOut, to go through a binary that has been compiled with this
Intel-only flag and remove that check

Once I ran the binary that was compiled with the Intel-specific flag
(-QxN) through iccOut, it was able to run on the FX51. it got
the same 22% performance boost that I saw on the Pentium4 .

it appears that in fact no Intel-specific optimization has been done if
the AMD processor is also capable to taking advantage of these same
optimizations.

From the way it looks right now, it appears that Intel
is simply "cheating" to make their processors look better against
competitor's processors.

dus wat denken jullie hiervan? moet dit serieus genomen worden? is intel dan werkelijk aan het "cheaten"?

om alles nog na te lezen en de util te zien die hij ervoor geschreven heeft de volgende link:

http://groups.google.ca/g...posting.google.com&rnum=1

[ Voor 9% gewijzigd door Puppetmaster op 10-02-2004 19:56 ]

[Verwijderd]

mmm, ik ga eerst maar eens het hele stuk lezen voor dat ik er wat over zeg.

het lijkt me wel sterk!

[Verwijderd]

Iets optimaal compileren voor een specifiek platform is al heel erg oud, de optie optimaliseren voor Intel is gewoon slecht gekozen, eigenlijk wordt daar bedoelt optimaliseer voor SSE(2,3). Aangezien de FX ook gewoon SSE en SSE2 heeft zal de optimalisatie daar ook goed werken.

Als je de Intel optimalisatie zou runnen op een systeem zonder SSE(2,3) dan zou het programma niet goed werken of crashen, of een lelijke fout geven.

Daarnaast worden benchmarks niet geoptimaliseerd voor een specifieke CPU, dan zou het geen eerlijke benchmark zijn. Als deze wel geoptimaliseerd wordt, dan wordt dat specifiek aangegeven. Zoals bijvoorbeeld bij Sandra, daar staat SSE2 er apart bij, omdat je daar geen reet aan hebt als de software er niet voor geoptimaliseerd is.

Eigenlijk dus een kwestie van ongelukkige naamkeuze, voor de rest niet veel aan de hand.

De auteur zegt zelf ook dat de CPU waarop je wil draaien SSE en SSE2 (en eventueel 3) moet hebben, maar hij kan schijnbaar zelf niet tot die conclusie komen.

Daarnaast is er ook een optimalisatie voor AMD systemen, en als je daar de nieuwste versie van gebruikt zal deze ook SSE2 gebruiken en dus een grotere boost veroorzaken omdat deze ongetwijfelt nog meer optimalisaties heeft.

[ Voor 25% gewijzigd door Verwijderd op 11-02-2004 00:49 ]

[Femme]

Het probleem met de Intel compiler is dus dat ie checkt op SSE2-compatibliteit én de vraag of de gebruikte CPU een Intel is. AMD-processors worden zodoende uitgesloten.

Daarnaast worden benchmarks niet geoptimaliseerd voor een specifieke CPU, dan zou het geen eerlijke benchmark zijn.

Bij SPEC gebeurd dat wel degelijk, maar omdat de source code vrij beschikbaar is wordt iedereen in theorie de mogelijkheid gegeven om de benchmark te optimaliseren voor de betreffende processor.

[Verwijderd]

Femme schreef op 11 februari 2004 @ 01:12:
Het probleem met de Intel compiler is dus dat ie checkt op SSE2-compatibliteit én de vraag of de gebruikte CPU een Intel is. AMD-processors worden zodoende uitgesloten.


[...]


Bij SPEC gebeurd dat wel degelijk, maar omdat de source code vrij beschikbaar is wordt iedereen in theorie de mogelijkheid gegeven om de benchmark te optimaliseren voor de betreffende processor.

Als deze wel geoptimaliseerd wordt, dan wordt dat specifiek aangegeven.

Natuurlijk controleerd de Intel compiler als je Intel optimalisaties geeft of dat je CPU wel een Intel is, anders kan het programma misschien niet goed werken. Heb je een AMD systeem dan optimaliseer je em toch voor een AMD systeem?

Dat dat programma toevallig als enigste optimalisaties het gebruik van SSE en SSE2 opcodes heeft is toeval, er hadden ook specifieke cache of andere optimalisaties in kunnen zitten die een AMD niet goed aankan. Dat de FX (alle A64) ook SSE2 aankunnen is daarbij ook toeval. Als je de nieuwste AMD compiler pakt dan zal die ook SSE2 erbij nemen (als je em voor A64 optimaliseerd) of je kan em zelfs zo compileren dat ie ook 64-bit opcodes gebruikt om op die manier nog een flinke snelheidswinst neer te zetten.

De controle van Intel is logisch (en ook nodig op systemen die geen SSE2 hebben anders crashed het programma) dus wat is hier mis mee?

[SG]

Verwijderd schreef op 11 februari 2004 @ 03:11:

Natuurlijk controleerd de Intel compiler als je Intel optimalisaties geeft of dat je CPU wel een Intel is, anders kan het programma misschien niet goed werken. Heb je een AMD systeem dan optimaliseer je em toch voor een AMD systeem?

Dat dat programma toevallig als enigste optimalisaties het gebruik van SSE en SSE2 opcodes heeft is toeval, er hadden ook specifieke cache of andere optimalisaties in kunnen zitten die een AMD niet goed aankan. Dat de FX (alle A64) ook SSE2 aankunnen is daarbij ook toeval. Als je de nieuwste AMD compiler pakt dan zal die ook SSE2 erbij nemen (als je em voor A64 optimaliseerd) of je kan em zelfs zo compileren dat ie ook 64-bit opcodes gebruikt om op die manier nog een flinke snelheidswinst neer te zetten.

De controle van Intel is logisch (en ook nodig op systemen die geen SSE2 hebben anders crashed het programma) dus wat is hier mis mee?

Ik denk dat jij niet zo volledig van de situatie op de hoogte bend en wat relevante bijzonderheden mist.

Meeste Commerciele apps word MS visual studio gemaakt Microsoft compiler techniek voor de P4 tijd was dat 5.0 en dat is PII optimised. nog niet een SPIII en daar liep K7 ook op ongeoptimaliseerd deed ie het veel beter dan de P4.

iNtel heeft zijn eigen compiler divisie AMD niet die is afhankelijk van derden Microsoft, linux dus
De NEtburst core is daar erg afhankelijk van omdat het oude code slechter aankan, dus ook veel winst te behalen van eigen complier.


Daarnaast checkt iNTel plugin compiler niet of 'n CPU SSE(2) heeft maar of het 'n intel CPU is en welke zo weet het wel of geen SSE2 en andere merken worden hierdoor opzettelijk uitgesloten.

De clou komt nu:
Dit heeft de man in die bron gehacked waardoor het nu wel werkt op AMD SSE2 CPU's

dus dit hele verhaal verbaast me helemaal niet.

Alleen heb je er niks aan omdat de consument afhankelijk is hoe de Software firma's hun software compileren.

Als software firma's alleen de plugin van intel gebruiken kan AMD flink benadeeld worden

Om iNTel en AMD optimaal benutten moeten ze binairies genereren met intel compiler én standaard MS compiler(aangezien er geen AMD plugin compiler is)

Gezien AMD64 wordt tegelijk met amd 64bit ondersteuning ook de hele architektuur goptimaliseerd.
Code wordt dan naast 64bit ook k8 optimized.

Ook 'n reden om als AMD bezitter op de aMD64 wagen te stappen aangezien als de softqware markt zo ver is je altijd zeker van bent dat je eindelijk AMD optimized code hebt totdat er x86-64 intel compilers komen die alleen voor tejas optimizen.

Wordt eens stijd dat AMD ook wat actiever op de compiler deel aan de weg timmert.

[Puppetmaster]

ow, okee
een beetje een storm in een glas water dus...

blijft wel dat het wel zo sociaal van intel was geweest als de compiler alleen zou checken op SSE2 mogelijkheid van de processor en niet specifiek intel processor...
maar daar zijn het dan weer concurrenten voor denkik maar