Intels kompilatorer genererar medvetet dålig kod för AMD

[Andax]

Jag har sett Intel som ett ganska seriöst företag, men efter att jag såg att de medvetet har gjort så att sämre optimerad kod körs om det är en AMD eller VIA processor så har jag ändrat uppfattning. På t.ex. VIA nano kan man fejka CPUID och få vissa program att köra dubbelt så fort om man lurar programmet att det körs på en Intelprocessor!!

T.ex. http://www.agner.org/optimize/blog/read.php?i=49#49

Sen är de väl lite väl paranoida när de stoppar sökmöjligheten på AMD på deras site. Söka på AMD funkar inte, söka på test funkar utmärkt.

http://www.intel.com/content/www/us/en/ ... ages=en_US (AMD)
http://www.intel.com/content/www/us/en/ ... ages=en_US (test)

[AndLi]

Kan du skärmdumpa din AMD sökning? Här funkar det utmärkt...

[sodjan]

Här med, får 4388 träffar...

[Andax]

Det är resultatet jag får upp hela tiden när man söker på amd på deras huvudsida. Söker jag på annat så hittar den resultat.

intel_amd_search.png

[sodjan]

Fungerar OK både från båda dessa sidor:
http://www.intel.com/content/www/us/en/homepage.html
http://www.intel.se/content/www/se/sv/homepage.html

[Maalobs]

Det ser ut som att det blev timeout i sökningen just när du prövade, det har nog inget att göra med själva sökordet.

Vad händer när du försöker igen?
http://www.intel.com/content/www/us/en/ ... eyword=amd

Även för mig blir det 4388 träffar.

[AndLi]

Såhär ser du ut här, både chrome och Firefox funkar fint...

[Andax]

Det verkar vara något skumt med sökningen. Om jag har med "&lstLanguages=en_US" så hittar den inte sidor med AMD, men om man plockar bort det från URL så funkar det.
Men är "&lstLanguages=en_US" och man söker efter något annat så funkar det.

Kanske bara slumpen att det inte funkar för mig???

[sodjan]

Tja, vad är "slumpen" egentligen...

Dina länkar så som du postade dom i första inlägget fungerar ju
bra för alla andra (som har testat). Tja, slumpen kanske...

> Om jag har med "&lstLanguages=en_US"

Jag kan lägga till det utan problem.

Posta *kompletta* länkar istallet. Gärna med URL-taggar så att man
ser hur de ser ut direkt i inlägget. Eller så gör vi något annat...

[Andax]

Det är kompletta URL som jag klistrade in i mitt första inlägg. Hovra över dem så ser du hela url.

Kod: Markera allt

http://www.intel.com/content/www/us/en/search.html?keyword=amd&lstLanguages=en_US
http://www.intel.com/content/www/us/en/search.html?keyword=test&lstLanguages=en_US

Tar jag och copy-n-paste av ovanstående länkar i webläsarens (IE9) addressfält så funkar inte den första (page unavailable) medan den andra funkar.

Nu var det väl inte meningen att fokus skulle hamna på intels sökfunktion, utan att de genererar kod som ger sämre prestanda beroende på vad slutanvändaren kör på för dator. Trots att man kör på en 100% kompatibel processor så väljer den genererade koden att köra en långsammare version om det inte är en intelprocessor.

[sodjan]

Funkar både i FF 14.0 och IE8 här. IE9 har jag inte.
Aja, vi släpper det...

När det gäller koden så försvarar sig Inter med att de måste ha
en lite konservativ hållning till arkitekturer som de inte har full
kontroll över. Finns en viss logik i det. Det viktigaste för Intel
bör vara att det faktiskt fungerar över huvudtaget. Det var också
någon timing sak med att AMD hårdvara inte var tillgänglig med de
aktuella utökningarna då en viss version av kompilatorn släpptes.
De vill bara stödja features som du även kan testa/verifiera.

Men kör man benchmarks så får man ju vara tydlig med att det är
lika mycket en benchmark av kompilatorn som av hårdvaran.

Om jag fattade rätt så sker denna kontroll vid compile-time.
Vad händer om man bygger på en Intel maskin och kör på en AMD?
Har den även denna kontroll inbyggt i run-time?

[Andax]

Nej, det är vid exekvering av den kompilerade koden som checken görs av en funktion "CPU dispatcher". CPUID innehåller info om tillverkaren och vilka instruktioner som stöds, typ SSE2, SSE3 etc.
Intel har valt att först kontrollera om det är 1) intel eller 2) något annat, typ AMD, VIA
Om 1) så körs optimerad kod beroende på instruktionsset som stöds. Om 2) kör generisk kod som är suboptimal oavsett om SSE mm stöds.

Ganska fult upplägg. Ska visst gjorts så sedan 2003 och görs så fortfarande. Rätt sätt är att checka vilka extensions som stöds och köra därefter.

[sodjan]

OK. Läste bloggen igen och det verkar vara vid run-time, ja.

Aja, Intel är "bara" ett företag så de får väl göra som de vill.
Och som sagt, de kan säkert tekniskt motivera sina val...
Det egna valet man har är att köra en annan kompilator.

[ds77]

Nu borde intel kunna räknas som marknadsledande och då brukar det inte längre vara "marknaden" som fullt ut styr vad man kan göra, men det intressanta kanske är att se hur stor marknadsandel deras kompilator har? Någon som har en uppfattning?

[Andax]

>> Aja, Intel är "bara" ett företag så de får väl göra som de vill.

Nej, det får inte göra som de vill. De har numera kravet på sig att de måste informera användaren att begränsningen finns och ska även bekosta merkostnaden att kompilera koden med en alternativ kompilator (inte nödvändigtvis deras egen) där begränsningen inte finns.

Nu vet jag inte hur stor marknadsandel de har men om de har en betydande andel så bör de ur konkurrenslagstiftningen inte få snedvrida konkurrensen än mer.