Intel's "cripple AMD" function:Will Intel be forced to remove the "cripple AMD" funct

[Solus Corvus]

I didn't say he COPIED someone's work, but he DID use the SAME words his links used just changed the version number of the compiler.
The problem is not whether he copied someone's text - I think he mistakenly put the wrong compiler version in his text.

It's more then a version number typo. He says the problem is still there today, and this is a current post. If he's wrong then he's outright lying.

And had they been doing it for all this time (5+ years since ICC 7.1), enough customers would have dropped using them, don't you think? Not to even mention someone would have sued them by now for monetary compensation.

Not if the code still runs faster on AMD machines then code from other compilers. You have pointed that out often enough.

Did more checks. There is a check for GenuineIntel - I didn't look where it is and what id does after it though.

It probably wouldn't be a contiguous string. In the comments he says:

Remember to check for the vendor string "Genu", "ineI", "ntel" in all DLLs as well.

These words from the OP article make most sense:
"In other words, they claim that they are optimizing for specific processor models rather than for specific instruction sets. If true, this gives Intel an argument for not supporting AMD processors properly."
Not good wording, but somewhat what I wanted to say. Now, unless some words from ICC manual say otherwise, there's no legal stand to ask Intel to change the current behavior.

If it's not using SSE, SSE2, and SSE3 on AMD machines when you compile with the t7 flag then it is indeed a bug.

http://software.intel.com/en-us/arti...amd-processor/

[alfaunits]

It's more then a version number typo. He says the problem is still there today, and this is a current post. If he's wrong then he's outright lying.

I jumped the gun too fast, as I mentioned later he is right - the check is still there (though I don't have the time to test what it does).

I can compile two test programs to see, but I need a guineapig with an AMD processor to test that.
A program for SSE3 CPUs only (/QxP or /QxO) patched and unpatched.

/QxT (most optimized) flag is actually quite specific - INTEL processors only!
Here's what it says:

    P  Intel(R) Core(TM) Duo processors, Intel(R) Core(TM) Solo processors,
       Intel Pentium 4 and compatible Intel(R) processors with Streaming
       SIMD Extensions 3 (SSE3) instruction support
    T  Intel(R) Core(TM)2 Duo processors, Intel(R) Core(TM)2 Quad
       processors, and Intel(R) Xeon(R) processors with SSSE3
    O  Intel(R) Core(TM)2 Duo processors.  Code is expected to run properly
       on any processor that supports SSE3, SSE2 and SSE instruction sets
/arch:{SSE|SSE2}
     same as /QxK and /QxW respectively

Not if the code still runs faster on AMD machines then code from other compilers. You have pointed that out often enough.

If they say it should work but it doesn't that's a different thing. (i.e. if they say the generated code should run SSE3 path on AMD processors but it doesn't, that's a different thing from not saying it and running default code path).

If it's not using SSE, SSE2, and SSE3 on AMD machines when you compile with the t7 flag then it is indeed a bug.
http://software.intel.com/en-us/arti...amd-processor/

That wording also seems quite specific that 64-bit code would default to the most simple one on AMD machines. (when a 64-bit app is compiled)

The above is for Fortran compiler, though, I only have ICC to test.

[little_scrapper]

The people that do not seem to be getting it; I can only assume they didnt read the whole thing or failed to understand what intel was doing. Their software was written to actually LOOK to see what CPU was being used; if it WASNT a "genuine intel" cpu, intels software compiler switched to the slowest possible code it could find. Intel wrote the software to intentionally cripple the compiler performance on non-intel cpu's.

They made a decision to write software that intentionally and deliberately hurt non-intel cpu users. That is against the law. Yes, they are not required to go out of thier way to help the competition, they are not required to spend thier time optomising for the competition, but they absolutely cannot deliberately write code that hurts the competition.

[STEvil]

They made a decision to write software that intentionally and deliberately hurt non-intel cpu users. That is against the law. Yes, they are not required to go out of thier way to help the competition, they are not required to spend thier time optomising for the competition, but they absolutely cannot deliberately write code that hurts the competition.

They can actually, or rather could before the FTC said they couldnt. Where it gets sticky is that they made a few claims which gave leeway in either direction and a few people took notice.

It is lazy to not enable basic performance enhancing features without notation.

[HiJon89]

The people that do not seem to be getting it; I can only assume they didnt read the whole thing or failed to understand what intel was doing. Their software was written to actually LOOK to see what CPU was being used; if it WASNT a "genuine intel" cpu, intels software compiler switched to the slowest possible code it could find. Intel wrote the software to intentionally cripple the compiler performance on non-intel cpu's.

They made a decision to write software that intentionally and deliberately hurt non-intel cpu users. That is against the law. Yes, they are not required to go out of thier way to help the competition, they are not required to spend thier time optomising for the competition, but they absolutely cannot deliberately write code that hurts the competition.

That's one way to look at it, another is that it checked for "GenuineIntel", and if it found a non-Intel CPU it went ahead and compiled the code normally. If an Intel CPU is found, it used the appropriate optimization. So the compiler isn't "switched to the slowest possible code" it just simply compiles the code like normal...

[Smartidiot89]

That's one way to look at it, another is that it checked for "GenuineIntel", and if it found a non-Intel CPU it went ahead and compiled the code normally. If an Intel CPU is found, it used the appropriate optimization. So the compiler isn't "switched to the slowest possible code" it just simply compiles the code like normal...

The "normal path" is using said instructions

Yes Intel can release compilers optimized for their uArch and aren't responsible to optimize for AMD or VIA that I agree with - that's fair play. But checking the CPUID Vendorstrong to decide which code path to take is wrong.

[HiJon89]

The "normal path" is using said instructions

No, using optimized instruction extensions is not the normal path, it is an optimization.

[little_scrapper]

That's one way to look at it, another is that it checked for "GenuineIntel", and if it found a non-Intel CPU it went ahead and compiled the code normally.

But thats not what the article said. It said it looked for the cpuID and if it detected a non-intel cpu it PICKED the SLOWEST path. That is what got the FTC's arse hairs twitching.

[HiJon89]

But thats not what the article said. It said it looked for the cpuID and if it detected a non-intel cpu it PICKED the SLOWEST path. That is what got the FTC's arse hairs twitching.

My reading from the article is that once the compiler recognizes that the CPU is not manufactured by Intel, it doesn't do any further checks to see which instruction set extensions the CPU supports, it just continues compiling without these optimizations. The compiler doesn't look at all possible versions of the compiled code and run internal unit tests so that it can "pick" the slowest version to output.

[alfaunits]

@scrapper - you're not reading. Some agree, some disagree with you on that - we DO get it. We just disagree on the topic!

OT: Hijon, who's the girl in your avatar??

[HiJon89]

OT: Hijon, who's the girl in your avatar??

Alicia Sacramone from the US Olympic gymnastics team

[Agner]

Thank you everybody for your enthusiastic discussion of my blog post. XtremeSystems have not validated my registration on this forum until now. Well, all arguments on both sides of the controversy have already been voiced here - no reason for me to add anything.

I have made a CPUID manipulation tool that makes it possible to test if the performance of a program changes when you change the CPUID family, model number and vendor string. Unfortunately, my program works only on VIA Nano CPUs. It's much more complicated to make a similar tool for AMD and Intel CPUs.

If anybody out there want to do some relevant testing, you just need a computer with a VIA Nano (A VIA Mini-ITX board is cheap and it fits into a standard desktop cabinet). If you find any benchmark programs or other CPU intensive programs with an unfair CPU dispatching then please let me know the details.

[Judaeus Apella]

Ugh... this is why I never buy intel products. Really... they're low down bastards. They do crap like this all the time. They recently got sued in the UK for paying off store chains not to sell AMD and other competing products. That's just low and now this too? I've also heard about them doing a bunch of other crappy things, like blacklisting companies that make computer components compatible with competing CPUs so they can push them into doing what they want, and harassing journalists who've published unflattering facts about their company practices publicly. I read on news website years ago, written by the guy it was done to, that his house was broken into and torn apart, he was spammed with email threats, harassed on the phone, and they even called and told him they were watching his little girl play in the school yard. That's just insane. I'm sure they probably settled the dispute out of court or he ran, otherwise one of you guys would have heard about it. It might still exist on Google somewhere.

[STEvil]

Ugh... this is why I never buy intel products. Really... they're low down bastards. They do crap like this all the time. They recently got sued in the UK for paying off store chains not to sell AMD and other competing products. That's just low and now this too? I've also heard about them doing a bunch of other crappy things, like blacklisting companies that make computer components compatible with competing CPUs so they can push them into doing what they want, and harassing journalists who've published unflattering facts about their company practices publicly. I read on news website years ago, written by the guy it was done to, that his house was broken into and torn apart, he was spammed with email threats, harassed on the phone, and they even called and told him they were watching his little girl play in the school yard. That's just insane. I'm sure they probably settled the dispute out of court or he ran, otherwise one of you guys would have heard about it. It might still exist on Google somewhere.

There was a thread a month or two ago about that... Liquid3D (Keith) was involved in it somehow.

R.I.P Keith btw.

[Judaeus Apella]

Yeah, I miss the guy.

But I won't so much as touch an Intel product. I hate those bastards and I tell friends not to buy them either because of their low down and illegal business practices. Working for them or buying their products.... you might as well just sign your soul to the cheapest bid.