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

11–20 of 83 posts

Re: Intel's "cripple AMD" function

#11

Post by barrkel »

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?

It's pretty common for runtime libraries to optimize low-level routines like memcpy, math, etc. with multiple different paths chosen on the basis of CPU capability bits. It's not the whole code that's twice the size; it's small functions which are implemented 2 or 3 or 5 times depending on what features are available.

Re: Intel's "cripple AMD" function

#12

Post by wtallis »

nvoorhies wrote: post #6
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.…

Have you actually looked at the details of the AMD errata? I scanned through quite a few, and none of them looked at all relevant to whether a compiler should enable certain SIMD extensions. Also, for the bugs that do need workarounds, the fix is typically in the BIOS or kernel, not the compiler.

Regardless of whatever bugs may or may not exist in AMD's chips, it is anti-competitive for Intel's compiler to refuse to enable SSEx extensions on AMD processors that claim compatibility, when the user has requested SSEx instructions to be used, unless Intel has specific knowledge that AMD has never produced a sufficiently bug-free implementation of SSEx.

Re: Intel's "cripple AMD" function

#13

Post by jrockway »

Sounds like AMD should just start setting the vendor string to "GenuineIntel", then. (This is something like the "like Mozilla" in every user agent string. If dumb software is going to do dumb tests, and you need to fool the dumb test to get your interoperability.)

Re: Intel's "cripple AMD" function

#14

Post by rbanffy »

jrockway wrote: post #13

Sounds like AMD should just start setting the vendor string to "GenuineIntel", then. (This is something like the "like Mozilla" in every user agent string. If dumb software is going to do dumb tests, and you need to fool the dumb test to get your interoperability.)

Better yet: make it writable.

That way the OS could change it per process/thread/context and the code would be happy.

Re: Intel's "cripple AMD" function

#16

Post by loudtiger »

jrockway wrote: post #13

Sounds like AMD should just start setting the vendor string to "GenuineIntel", then. (This is something like the "like Mozilla" in every user agent string. If dumb software is going to do dumb tests, and you need to fool the dumb test to get your interoperability.)

sounds like the Pre and iTunes. haha.

Re: Intel's "cripple AMD" function

#17

Post by wmf »

rbanffy wrote: post #14
jrockway wrote: post #13

Sounds like AMD should just start setting the vendor string to "GenuineIntel", then. (This is something like the "like Mozilla" in every user agent string. If dumb software is going to do dumb tests, and you need to fool the dumb test to get your interoperability.)

Better yet: make it writable. That way the OS could change it per process/thread/context and the code would be happy.

VIA has a writable vendor string which they have used to reveal this type of shenanigans in the past.

Re: Intel's "cripple AMD" function

#18

Post by pmjordan »

ars wrote: post #10
ShabbyDoo wrote: post #8

Earlier quoted context omitted.

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.

I suspect it patches a jumptable at initialisation time based on CPU type, and all the code used by one type of CPU is bunched close together. The unused code probably isn't even paged into physical RAM.

Re: Intel's "cripple AMD" function

#19

Post by DougBTX »

ars wrote: post #10
ShabbyDoo wrote: post #8

Earlier quoted context omitted.

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.

Certainly. These are performance optimisations, they must measure results.

Re: Intel's "cripple AMD" function

#20

Post by drewcrawford »

I was an intern for AMD a few years ago (these are my views and not AMD's). I was pretty skeptical about AMD's antitrust claims against Intel until I went to work there. I'm as free market as they day is long, but there's a whole untold story of the evil things that go on in the back meeting rooms, even outside of sales, where most of the public lawsuit claims are/were.

The thing to remember is that AMD is a small fraction of the size of Intel, and they have to cover the same market segments. If they try to specialize (say, servers, or notebooks), Intel will just sell that segment at a loss. AMD has to cover everything with only a fraction of the people to stay competitive, and it's really hard.

Even while I was there, we had what I suspect (but have no proof) were incidents of people leaking product plans, roadmaps, etc. (but no IP) to Intel. It's sad, really.

Post reply on HN