Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel's "cripple AMD" function

agner.org

Post reply on HN
Print view View original

1–10 of 83 posts

Re: Intel's "cripple AMD" function

#2

Post by NathanKP »

This doesn't really make any sense. All you would need to do is compile the code on an Intel machine to get fast speed and then you can run it on an AMD machine. It shouldn't really cause any problems as long as developers build on genuine Intel machines. Of course that it irritating, but it shouldn't cause any slowdown on other machines.

Re: Intel's "cripple AMD" function

#3

Post by adame944 »

Bottom line: it's a business decision. Code generated by the Intel compiler "works" on AMD chips, although it may not be optimal. For Intel to support the optimal codepaths on AMD chips would require a substantial amount of research. I don't think they're intentionally crippling AMD chips; just declining to invest the effort to support them optimally.

Re: Intel's "cripple AMD" function

#4

Post by ShabbyDoo »

NathanKP wrote: post #2

This doesn't really make any sense. All you would need to do is compile the code on an Intel machine to get fast speed and then you can run it on an AMD machine. It shouldn't really cause any problems as long as developers build on genuine Intel machines. Of course that it irritating, but it shouldn't cause any slowdown on other machines.

I think the compiler generates code which checks processor type at runtime, not compile time. If the compiled code is running on an AMD processor, the "safe" version of the compiled code is chosen automagically.

Re: Intel's "cripple AMD" function

#5

Post by NathanKP »

ShabbyDoo wrote: post #4
NathanKP wrote: post #2

This doesn't really make any sense. All you would need to do is compile the code on an Intel machine to get fast speed and then you can run it on an AMD machine. It shouldn't really cause any problems as long as developers build on genuine Intel machines. Of course that it irritating, but it shouldn't cause any slowdown on other machines.

I think the compiler generates code which checks processor type at runtime, not compile time. If the compiled code is running on an AMD processor, the "safe" version of the compiled code is chosen automagically.

Wouldn't that make the code twice as large?

Re: Intel's "cripple AMD" function

#6

Post by nvoorhies »

adame944 wrote: post #3

Bottom line: it's a business decision. Code generated by the Intel compiler "works" on AMD chips, although it may not be optimal. For Intel to support the optimal codepaths on AMD chips would require a substantial amount of research. I don't think they're intentionally crippling AMD chips; just declining to invest the effort to support them optimally.

In addition to just the question of what path is optimal, they'd have to keep track of all the bugs in AMD's, Cyrix's, Transmeta's, and other implementations which aren't the same as the bugs on Intel x86 chips. Falling back to a subset of the architecture that is more likely to produce the right behavior is the sane thing to do.

e.g. http://www.amd.com/us-en/assets/content_type/white_papers_an... v. http://download.intel.com/design/processor/specupdt/320836.p... - these aren't just a couple gotchas you can put on the back of an index card

Re: Intel's "cripple AMD" function

#7

Post by DarkShikari »

adame944 wrote: post #3

Bottom line: it's a business decision. Code generated by the Intel compiler "works" on AMD chips, although it may not be optimal. For Intel to support the optimal codepaths on AMD chips would require a substantial amount of research. I don't think they're intentionally crippling AMD chips; just declining to invest the effort to support them optimally.

That isn't exactly how it works.

The proper way to do it:

    if( CPUIDbits & SSE1_CAPABLE ) {enable SSE1}
    if( CPUIDbits & SSE2_CAPABLE ) {enable SSE2}
    [etc]
The even better way to do it:

    if( CPUIDbits & SSE1_CAPABLE ) {enable SSE1}
    if( CPUIDbits & SSE2_CAPABLE ) {enable SSE2}
    if( CPU is Athlon 64 ) {disable some SSE2 functions}
    if( CPU is Pentium-M ) {disable all SSE2 functions}
    [etc]
Intel's way of doing it:

    if( CPU is Pentium 3 ) {enable SSE1}
    if( CPU is Pentium 4 ) {enable SSE1/SSE2}
    if( CPU is Core 2 ) {enable SSE1/SSE2/SSE3/SSSE3}
    [etc]
Practically all sane applications do things the first way; a couple do things the second way. Anyone doing things the third way is just asking for trouble both in terms of future compatibility and resilience to unexpected situations. For example, some VMs disable certain instruction sets, which would result in SIGILLs when using the last method.

Re: Intel's "cripple AMD" function

#8

Post by ShabbyDoo »

NathanKP wrote: post #5
ShabbyDoo wrote: post #4

Earlier quoted context omitted.

I think the compiler generates code which checks processor type at runtime, not compile time. If the compiled code is running on an AMD processor, the "safe" version of the compiled code is chosen automagically.

Wouldn't that make the code twice as large?

Perhaps, but size doesn't really affect runtime performance that much, especially if most codepaths are never execute -- no processor cache churn because the unused paths are never executed.

I don't really know anything about this compiler, so I'm certainly speculating. My assumption is that one writes some function foo() and the compiler prepends a dispatcher in front which forks (code paths, not processes) to one of N optimized but functionally equivalent codepaths based on the actual processor upon which the code runs.

Re: Intel's "cripple AMD" function

#9

Post by wtallis »

adame944 wrote: post #3

Bottom line: it's a business decision. Code generated by the Intel compiler "works" on AMD chips, although it may not be optimal. For Intel to support the optimal codepaths on AMD chips would require a substantial amount of research. I don't think they're intentionally crippling AMD chips; just declining to invest the effort to support them optimally.

Nope. Checking the vendor string to determine capabilities when the CPUID instruction already has flags for different capabilities is unjustifiable. When a CPU claims SSE2 support, the compiler should enable SSE2, regardless of the vendor string. If AMD's implementation of SSE2 is buggy, that's their problem, and Intel should have no trouble making it into a PR win.

This is really no better than printer manufacturers putting chips into their cartridges so that they can use the DMCA to prevent third parties from refilling or making compatible cartridges.

Re: Intel's "cripple AMD" function

#10

Post by ars »

ShabbyDoo wrote: post #8
NathanKP wrote: post #5

Earlier quoted context omitted.

Wouldn't that make the code twice as large?

Perhaps, but size doesn't really affect runtime performance that much, especially if most codepaths are never execute -- no processor cache churn because the unused paths are never executed. I don't really know anything about this compiler, so I'm certainly speculating. My assumption is that one writes some function foo() and the compiler prepends a dispatcher in front which forks (code paths, not processes) to one o…

Size does affect performance because of the cache.

If the forks are inline, and the cache works in blocks, then you are wasting cache space for code that never runs.

But considering it's intel I'm sure they thought of that.

Post reply on HN