Slashdot Mirror

Sorry, but that is bullshit. Intel started doing this very early on (in version 8 of their compiler), and none of their CPU capability checks looked at the specific architecture at all. The only thing they checked was the CPU capability flag, and they deliberately skipped that check unless the chip was from Intel.

They even cocked this up with their first iteration, such that instead of producing binaries that ran slowly on AMD chips it produced binaries that segfaulted on AMD chips. See http://www.swallowtail.org/nau... for the details.

This idea that "Ooh, although this chip advertises that it supports SSE2 we'd better not actually let it run any SSE2 instructions just in case they run more slowly than generic 386 code" is a valid excuse is just crap.

See http://www.swallowtail.org/nau... for a patch to the compiler that removes some (but not all) of the CPUID checks.

They did it with their C compiler in the past. When they detected anything but an Intel processor they didn't use the SMD instructions even when the processor indicated full support for SMD *IN THE INTEL DOCUMENTED WAY* You can Google for the details.

Or you can clicke here.

Hopefully we don't see intentionally crippled performance on non-Intel CPUs!

Checking for 'GenuineIntel' is fine, but the actual code emitted by the compiler goes straight to 'no additional capabilities' if it detects any other string. In other words, in the 32-bit compiler any non-intel chip is doomed to run the 'you are a bog-standard 386 with no MMX/SSE/SSE2 support' code path regardless of its actual capabilities. This 'feature' makes less difference in the 64-bit compiler (because the base level is a EM64T with SSE2, as opposed to a 386 with nothing for the 32-bit version), but as new instruction sets come online (SSE3, SSE4 and the like) this artificial crippling of AMD chips will start to show there as well.

And yes, you say you 'tell it like it is', but I've disassembled the actual code and it doesn't accord with your story. See http://www.swallowtail.org/naughty-intel.html for the gory details. The proof of the pudding is in the eating: if you patch one of our programs compiled with the Intel compiler to remove the Intel check it runs significantly slower on AMD chips (as in DOUBLE the runtime).

There is no technical reason for these checks to be there: they are purely a competitive ploy to cripple performance on AMD chips. If Intel released their compiler for free, then I'd say so what: they're allowed to make it a marketing tool. OTOH, they release it as a commercial product and charge me money for it: doing that and then deliberately crippling its performance is IMHO not acceptable.

Well this is a bit old, but apparently it doesn't and I cannot see it being all that likely that Intel will spend time and money making there compiler kickass on AMD.

Intel compiler crippled on AMD chips!
http://www.swallowtail.org/naughty-intel.html

Clearly it would take money and skills to have a compiler team at AMD, but that doesn't answer why they don't want to spend that money to compete with there main competitor in a vital area of their processors being the best they can be.

Enough with the toy, synthetic and vendor optimized benchmarks. Give us men real benchmarks and lots of them to ensure the results are consistent across the board and not due to specific vendor optimizations for we know certain vendors aren't very honest. Not to pick on Intel but check out the following url's as examples http://www.swallowtail.org/naughty-intel.html and http://www.technewsworld.com/story/49156.html.

Both 32 and 64-bit versions of both if available
Matlab, Mathematica, Maple
OpenSSL encyrption
Softimage, Maya, Modo
Oracle, MSSQL, Postgresql, Mysql

Feel free to add to the list. AMD looks like they have the architecture superiority while Intel's new Conroe will bandaid their architecture with a larger cache. Curious to see what happens to performance when cache is filled.

Intel does use the CPUID checking everywhere in its compilers and libraries and is eager to turn off SSE/SSE2/... optimizations whenever seeing non-Intel CPU.
Nothing new here.
http://www.swallowtail.org/naughty-intel.html
http://fahwiki.net/index.php/FAH_%26_QMD_%26_AMD64 _%26_SSE2

I released XQuest back in 1994-ish. The gameplay was vaguely similar to Crystal Quest, but the graphics, sound etc were all original. Buckland claimed I'd violated his copyright and asked me to pull the game. I played nice and changed aspects of the game that he'd claimed were too similar to Crystal Quest but he still waved copyright-infringement threats at me and demanded I stop distributing XQuest.
Eventually I called his bluff and he gave up, but the whole experience left a bit of a bitter taste. Interesting to see that he's now made some more money from the franchise...

I always thought that XQuest was even better than Crystal Quest, but then I'm biased :).

The best Crystal Quest clone i've played was XQuest on my old DOS box. I see the source is out now; perhaps it's time to port it to SDL if the licence permits.

It would be nice to just apt-get install xquest one day.

Sorry... here is the /. article on the issue, and details can be found here.

In brief: a library routine doesn't bother to check for the SSE support if CPUID doesn't return "Genuine Intel" as the vendor string, even though one can detect SSE/SSE2 support independent of the vendor string.

check out http://www.swallowtail.org/naughty-intel.html [swallowtail.org] Read carefully

There's a big difference between checking for non-Intel chips and checking for AMD chips. According to this:http://www.swallowtail.org/naughty-intel.html (from another thread), the compiled code branches to SSE* instructions if it detects GenuineIntel, or to generic 386 instructions if it doesn't detect GenuineIntel. If this is the case, the compiler doesn't act specifically against AMD, but rather generates code that performs poorly on non-modern Intel processors.

Sure. But what other mainstream i386 CPUs are out there that isn't AMD? VIA? Your Verilog implementation of the instruction set on your home PC? If that's the case, then both Cyrix and you should help AMD because they're obviously hating VIA and you too. If that's not the case, then AMD is the only major competitor to Intel, and the statement "looks for non-Intel" is EQUIVALENT to "looks for AMD."

The fact is, it is SUFFICIENT to only test for the presence of SSE/SSE2/SSE3 instruction set. Anything more, like "GENU" "INEI" "NTEL", is absolutely unnecessary. Afterall, why would Intel care if the code fails on non-Intel CPUs if ICC is only meant for Intel CPUs (which it isn't)? On the other hand, if the ICC is designed for other CPUs, then Intel obviously would know (afterall, Intel IS licensing the SSE/SSE2/SSE3 instruction set to AMD) the capabilities of said CPUs, in which case they should enable SSE/SSE2/SSE3 for CPUs capable of the instructions. Last I heard, there weren't any problems with AMD's SSE/SSE2/SSE3 implementation. Therefore, the bottom line is this boils down to a Catch22 situation and Intel should know better than to pull such cheap tricks. If Intel is going to assume that any CPU that implements the i386 instruction set does this without major problems, then why would they not assume the same with SSE/SSE2/SSE3?

Furthermore, if you actually read some of the user posts (and their links http://www.swallowtail.org/naughty-intel.html), you would have realized that ICC deliberately produces segfault code when the execution of the code doesn't find an Intel CPU. According to the article, this is with the -xK flag. That is, it produces ONLY SSE code, and NO fallback to i386 code. Yes, that means this code will fail on the original Pentium. However, in this case, Pentium will still try to execute the SSE code (and subsequently craps out), while AMD CPUs will not (and automatically segfaults). This kinda throws the "and then does 'i386' code path, which is less optimal" argument out the window....

Apps that crash are apps that apps compiled specifically with the flag 'use SSE' and that don't generate code for non-SSE machines. Intel, it seems, hid the 'check for non-Intel' bit inside the checks for SSE and SSE2 - see this site for more detail.

But let's be clear: Intel would be perfectly within their rights to make a generic non-Intel option which functions at the level of the safest (albeit slowest) common denominator. To begin to optimize and troubleshoot for alternate (competitor's) chips would be an absurd project for Intel to invest resources in. The question is this: Is AMD uniquely singled out here by the Intel compiler? (By name?) Or does the Intel compiler check the CPUID for a simple boolean of Intel or non-Intel.

according to this guy, it is in fact a boolean test of Intel/non-Intel. correct me if i'm wrong, but AMD is the only competing company to provide an SE2 solution, so i would go as far as to say this is singling them out. the Fortran compiler 7.1 executes a mov $0x1, 0x0 in the case of non-Intel chips, regardless of SSE support. compiler 8.0+ executes SSE instructions in the case of existing SSE support, optimized SSE2 instructions on Intel chips supporting it, and crippled SSE support on non-Intel ships.

if AMD is the only other provider of an SSE2-supporting chip, this could easily be construed as singling-out.

Not the CPU itself, but certainly the program that it's running: http://www.swallowtail.org/naughty-intel.html

http://www.swallowtail.org/naughty-intel.html
I'm going to go through this article. Looks awfully interesting.
There's a line between not optimising the competition, and torpedoing the competition.

This seems to be it. I haven't tested it yet.

A good investigation can be found at http://www.swallowtail.org/naughty-intel.html

http://www.swallowtail.org/naughty-intel.html/.

Take a look at this page for an example. Also, try here.