Linked by Thom Holwerda on Sun 3rd Jan 2010 20:32 UTC
General Development Here's something you probably don't know, but really should - especially if you're a programmer, and especially especially if you're using Intel's compiler. It's a fact that's not widely known, but Intel's compiler deliberately and knowingly cripples performance for non-Intel (AMD/VIA) processors.
Thread beginning with comment 402253
To read all comments associated with this story, please click here.
Don't like it don't use it
by bile on Sun 3rd Jan 2010 21:06 UTC
bile
Member since:
2005-07-08

If you don't like the code generated by the Intel compiler... don't use it. Why should they be forced to pay attention to competitor's products and make *their* compiler compatible with them unless ICC customers demand it? Using the most generic path is the only practical option when not knowing the specifics of the architecture.

The only thing anti-competitive here is people advocating Intel be made to do what they want them to by force.

Reply Score: -13

RE: Don't like it don't use it
by WereCatf on Sun 3rd Jan 2010 21:13 in reply to "Don't like it don't use it"
WereCatf Member since:
2006-02-15

If you don't like the code generated by the Intel compiler... don't use it. Why should they be forced to pay attention to competitor's products and make *their* compiler compatible with them unless ICC customers demand it? Using the most generic path is the only practical option when not knowing the specifics of the architecture.

You're totally off-the-base here. First of all, Intel themselves market ICC as being compatible with AMD and Via processors. Secondly, even if the compiler didn't do any kind of architechture-specific optimizations it could still choose the most appropriate path based on CPU's reported capabilities, ie. f.ex. if it supports SSE3 choose the path which uses SSE3. ICC intentionally chooses the slowest path for any other than GenuineIntel processors, even when the CPU reports its capabilities correctly.

Marketing it as completely compatible compiler and then pulling off such tricks actually IS anti-competitive.

Edited 2010-01-03 21:15 UTC

Reply Parent Score: 9

tylerdurden Member since:
2009-03-17

No such thing. Intel markets their compiler as being compatible with the X86 and EMT64 (and IA64) instruction sets from Intel processors. Have you even used icc?

Technically they still produce compatible code. Nowhere in intel marketing/literature they claim to produce optimized code produced for AMD microarchitectures.

The continual moving of the goal posts in order to fit some narratives can be fascinating.

Intel develops compilers for intel processors. Is that such a hard thing to comprehend? Or is there any sort of entitlement from your part that would bind intel to spend money and effort to schedule instructions for a competitor's part?

Such attitudes are even the more ridiculous, if you consider that there is a perfectly viable (and in most cases quite competitive) alternative like gcc which is completely free. Good grief....

Edited 2010-01-03 22:51 UTC

Reply Parent Score: 1

mabhatter Member since:
2005-07-17

most importantly, AMD and VIA are LICENSED to use the SSE2/3 etc. technology from intel and design their processors specifically to perform well with ICC generated code that the largest software vendors use. Intel is basically filching on it's own cross-license agreements for the technology by sabotaging performance of the products of other companies.

Reply Parent Score: 5

RE: Don't like it don't use it
by Praxis on Sun 3rd Jan 2010 21:27 in reply to "Don't like it don't use it"
Praxis Member since:
2009-09-17

Well there are two major issues that make this wrong, first Intel isn't telling its customers that their compiler deliberately nerfs non-Intel performance, this is most certainly ethically wrong may violate some consumer rights, you do have a right not to be lied to by corporations. Second Intel is a monopoly under anti-trust investigations. Monopolies are held to higher ethical standards so that they do not use their power to squash competition by means other than legitimate competition, doing a vendor id check in their compiler would fall under that kind of violation, an x86 complier should be an x86 complier, if their chips are better they shouldn't have to cripple their competitors to have advantage.

If Intel had been honest from the beginning this may not have been an issue, but since they lied and they are currently under anti-trust charges, forcing them to stop vendor string checking in their complier would be a reasonable part of their settlement.

Reply Parent Score: 3

tylerdurden Member since:
2009-03-17

Where, please tell us, where does Intel claim (or have they ever claimed) to produce optimized code for AMD processors with icc?

Reply Parent Score: 2

RE: Don't like it don't use it
by ngaio on Sun 3rd Jan 2010 21:30 in reply to "Don't like it don't use it"
ngaio Member since:
2005-10-06

Why should they be forced to pay attention to competitor's products and make *their* compiler compatible with them unless ICC customers demand it?


Your analysis seems to assume that an extreme form of selfishness is good for society and good for Intel. Fortunately for the rest of us, very few people make this assumption.

Reply Parent Score: 8

tylerdurden Member since:
2009-03-17

And your reply constitutes a massive red herring, and it is equally as invalid.


Since when has there been such a level of entitlement regarding compilers? Do you go around trashing The Portland Group because their compiler does not produce the code you feel entitled for your processor (even tough you haven't paid for their products). Should we trash IBM because their XL compiler suite does not produce optimal code for the latest embedded core by Freescale?

Reply Parent Score: 0

j.blechert Member since:
2006-01-04

disclaimer: I am not a programmer.
but in the article there is a link to a benchmark (pcmark2005), apparently compiled with icc. now as far as I got it they tested via's nano against intel's atom and the funny thing is that in various tests after chaging the CPUID on the nano the performance-gain was up to about 50%, with no change of the compiler or compiled software whatsoever, simply by telling the compiler to use a path that was optimized for SSE3 and whatnot.
as far as I know those things are standards and if AMD wouldn't implement them correctly, they wouldn't be able to report the capability of using SSE3. the argument was that inspite of reporting those capabilities correctly and no additional work needed from the compiler, it would choose on the CPUID rather than the actual capabilities, resulting in Intel having to tweak their CPUID to be able to have best performance with software compiled on earlier ICC versions, again no recompiling neccessary, the code is all there, but which gets executed is choosen based on the CPUID, not the actual capabilities of the CPU (there are flags for those too as you should know).

Reply Parent Score: 3

jabbotts Member since:
2007-09-06

The issue is not some oddity within the non-intel processors which Intel should be forced to recognize.

The issue is Intel intentionally writing icc so that it would introduce incompatibility in the resulting binary so that it run worse on other processors.

Think of a company that sells coffee makers. They also produce coffee and recommend it's use with there own makers of course (nothing wrong so far). They add a chemical identifier into there own coffee which can be recognized by the various models of maker the company sells. One can run any brand of coffee ground through the maker but it's designed so that it introduces a health risk into competitive brands. You want a refill on that cup a joe?

(edit): my analogy was a little off. It would be like the coffee maker intentionally taking twenty minutes longer to brew through grounds based on them being competitive brands.

Intel should just fix icc and make the issue AMD/VIA not supporting the optimized code rather than this "we get fast path, they get slow path" crap.

Edited 2010-01-03 23:37 UTC

Reply Parent Score: 2

Scali Member since:
2010-01-03

(edit): my analogy was a little off. It would be like the coffee maker intentionally taking twenty minutes longer to brew through grounds based on them being competitive brands.


Still wrong.
I think what you're looking for is something like this:
Last year's models of coffee makers took 20 minutes to brew.
The new models have a special 'turbo' mode, which cuts the brewing time down to 10 minutes.
Competing brands have also added a similar 'turbo' mode. However, the coffee of this particular brand will only recognize the 'turbo' mode of their own brand of coffee makers, and other brands, like older models of their own brand, will only use the standard 20 minute mode.

There is a difference between 'not enabling' and 'disabling'.
The former is NOT taking action, and the latter is explicitly TAKING action.
Intel only checks to see if the CPUs are their own brand, and then selects an optimized path. That's different from checking to see if they are any other brand, and specifically selecting a crippled path.

Edited 2010-01-03 23:49 UTC

Reply Parent Score: 2