Monday, December 2, 2013

Intel Compiler Degrades Performance for Non-Intel CPUs

how am i just hearing about this? this is old news, but worth a read if you don't know what i'm talking about.

why so late? why haven't others written about this?

i haven't searched thoroughly, but, reportedly, intel's ties (big advertiser) with tech blogs and publications has kept this from seeing as much exposure as it deserves.

intel does what?

i'll horribly summarize: intel makes some of the best and most widely used compiler and libraries that exist. they are used in tons of compiled installers. the catch: they unfairly optimize for genuine intel products.

they finally have a notice on their website, but it isn't incredibly obvious and isn't the fix the settlement after the court case with AMD demanded.

but they are intel!

the obvious issue is that processor shouldn't matter -- instruction set should:

if (this.processor supports SSE){use sse code} else {use non sse methods}

instead, the code looks like this:

if(this.processor is genuine intel){use best instruction set method} else {use the least optimized code}

in 2012, they did comply with some court order and offer refunds to those interested (misinformed purchasers who expected an impartial compiler/libraries). not enough.

still, this would be acceptable if the product was billed as an intel exclusive or they were making use of things competitors couldn't offer. it isn't (in this case).

Agner (see source link), who has done MUCH research on the topic, claims that we need to get glibc (a rival compiler) and it's libraries properly optimized. Since that is above my head, I thought getting this dirty practice exposed a few people at a time (the extent of my reach) would have to be my contribution.

*chuckles* ...and...you are surprised?

back when AMD took the performance crown (what, 10 years ago?), no. i've been an AMD supporter for a while since they price their products competitively. but since Intel has been the obvious performance leader for a while now...at least in per-clock work and power efficiency, i thought they'd let their products based on superior manufacturing process speak for their-selves. no, gotta pull (or, not rectify) some underhanded stuff like this? and here i was pulling for them to be competitive with ARM.

source

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

No comments: