Intel intentionally compromising license?

[Claymonkey]

http://www.techreport.com/onearticle.x/8547

Apparently one of AMD's points in the antitrust case against Intel is that Intel's compilers ignore if a non-intel cpu can actually handle mmx, sse, sse2 and sse3 and makes it use a slower thread of a compile. It seems to be a simple tweak to enable a compile to ignore the "genuine intel" and let the cpu do what it can, but you have to KNOW about that in the first place.

So what are everyone’s thoughts on that? Is it ok on Intel’s part to do this? Personally I don’t think so. They sell their tech to other companies to use in their tech…. BUT if a program is made using THEIR compilers… oh well. Sounds like a bad business practice.

[schmosef]

Very interesting.

[Kurt]

I can see why they would produce at least 2 code paths.

The compiler is optimized to produce the best code for Intel CPUs since they KNOW every last thing about them and then there's the second code path, a generic one, that would just run on EVERYTHING else.

It's up to AMD to contract Intel to optimize their compiler to produce the best code for their processors too. If Intel specifically REFUSES to do so, they might have a case.

[Umfriend]

I can see why they would use at least 2 code paths.

The compiler is optimized for Intel CPUs since they KNOW every last thing about them and then there's the second code path, a generic one, that would just run on EVERYTHING else.

It's up to AMD to contract Intel to optimize for their processors too. If Intel specifically REFUSES to do so, they might have a case.

They're not asking to optimise the compilers for AMD chips. They're just syaing that the compiler produces code, whether compiled on an Intel or AMD chip, that will or won't run SSE/SSE2 depending on the brand, not on the capabilities of a CPU (as identified by an intel desigend mechanism) the program is running on.

So you've got this AMD CPU, and you've got this program. It's got the efficient code, that is code that uses SSE/SSE2. Your AMD CPU supports this, as can be seen by any program using an Intel devised routine. What happens? Your program got inneficient code as well and that is being run, simply cause it's an AMD chip.

I'd definately call this abuse of market power.

[Kurt]

Not what I meant but thx anyway, I edited the post for clarity.

[Umfriend]

Not much clearer to me. Are you implying that the code optimised towards Intel CPU's would not run on AMD chips at all?

[Umfriend]

Or as someone else put it:

The problem is not that they can't guarantee that the AMD chips work. The problem is they are generating instruction streams that run JUST FINE on AMD chips and their runtime code DISABLES that code path (if you use the recommended or default compiler settings).

It's AMD's job to make sure their implementation of IA32 + whatever extensions is good, not Intel's job to disable code on their chips--except based on the processor capability word. (Whatever "flags" from /proc/cpuinfo is properly called.)

[Kurt]

Not much clearer to me. Are you implying that the code optimised towards Intel CPU's would not run on AMD chips at all?

No, I'm saying it wouldn't run the optimized-for-Intel code on an AMD chip (or ANY other brand), rather use the generic one.

Again, if the compiler SPECIFICALLY and SOLELY disables the optimized-for-Intel code when running on AMD, then they have a case.

If the compiler disables the optimized code for EVERY NON-INTEL chip, then Intel can always argue they're trying to maintain the highest possible compatibility so screw AMD and their antitrust case.

[Umfriend]

But why? I find it hard to swallow that *any* code using MMX/SSE/SSE2 would be considered "optimised for intel". There is *no* reason to assume MMX/SSE/SSE2 should not be considered "generic" for processors that say they do support these extensions.

[Kurt]

Yes and no.

What you say is right but you consider the capabilities of the CPU, not the brand. According to AMD, Intel's compiler considers the BRAND of the CPU and then produces runtime code that will DISABLE running parts of the program with all sorts of extensions like MMX and whatnot, in this case specifically when it finds the Authentic-AMD CPUs.

The RIGHT way for a compiler would of course to optimize for EACH processor, according to its capabilities. NOT in the interest of Intel for sure, but not SPECIFICALLY against AMD. It's against everyone alright.

You have to understand, however, that the wording of the claim is very important when you go to court. You can be absolutely right but still lose because what you demonstrate is not exactly what you claimed. If AMD's is too generic or too specific, they'll lose.

[Nowhere]

Uhmm...but apart from looking for the brand, the program looks also for flags of SSE/SSE2/...
WHY it doesn't use them if they're there? It would be even better for Intel if SSE on AMD was broken. Apparently AMD is confident that it isn't...
(in the same manner as you put the whole SSE thing, GCC & MS compiler (because I doubt Intel would do that ) should not run 64bit binnaries on Intel EVER)

[Kurt]

I don't know what the compiler looks for in particular, but AMD CLAIMS it only takes a look at Authentic-AMD and then everything runs on a slow code path.

The problem is obviously that Intel is not solely a compiler vendor. If they were, you can bet their compiler would run the best code possible for any CPU out there.

[Umfriend]

Again, if the compiler SPECIFICALLY and SOLELY disables the optimized-for-Intel code when running on AMD, then they have a case.

If the compiler disables the optimized code for EVERY NON-INTEL chip, then Intel can always argue they're trying to maintain the highest possible compatibility so screw AMD and their antitrust case.

Bollocks. According to Intel, these compilers are:

The Intel® C++/Fortran compilers are vectorizing compilers for Windows and Linux that automatically convert sequential code into a form that exploits the Intel® MMX™ technology and streaming-SIMD-extensions (SSE/SSE2/SSE3) for IA-32 processors and Intel® EM64T, and the Intel® Wireless MMX™ technology for the Intel® Xscale® microarchitecture.

AFAIK, The AMDs are IA-32 processors and the AMD-64s are IA-32 compatible. Nowhere does it say it'll only support one or more brands of CPUs.

So I wonder whether you still feel that it's up to AMD to contract Intel to optimise the compliers for AMD chips ir simply that it's up to Intel not to run non-SSE code on purpose while they damn well know the CPU says it's SSE compatible.

[Kurt]

AMD CPU's are IA32 or IA32-compatible? I don't know.

IMO, a compiler should produce the best code for the target CPU.

If Intel does sth BAD/ILLEGAL, they should be punished. No doubt about that.

About AMD contracting Intel to optimize its compiler, yes I think they should still try it. If Intel says NO, it will play against them [Intel].

Sth about AMD I still don't understand is why they don't focus more on chipsets and compilers. OK they have limited resources with respect to Intel, but HECK, they're a MULTI-BILLION dollars company. The can surely afford a compiler team and their chipset business could become a major profit center, just as chipsets are for Intel.

They're the ones in the best position to extract the most of their CPUs, yet they rely on 3rd parties to do so. Said 3rd parties having huge interests in the Intel market, except for Nvidia - until recently.

OEM are also looking for packaged deals and stability. Only Intel will offer that and that too plays against AMD.

[Claymonkey]

I think the fact that you can remove that ONE trigger yourself when you compile your code (IF you know about it, and apparently many do), and you have no problems and AMD chips generally get a 10% boost in performance from it should answer the question of whether they are playing it safe or playing in an unkosher manner. BUT, I'm not a coder so I might be missing something (but I doubt it).