Intel's "cripple AMD" function

http://www.agner.org/optimize/blog/read.php?i=49

by kierank • 17 years ago

212 80 17 years ago

NathanKP2• 17 years ago

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.

ShabbyDoo2• 17 years ago

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.

NathanKP2• 17 years ago

Wouldn't that make the code twice as large?

adame944• 17 years ago

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.

nvoorhies2• 17 years ago

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

wtallis2• 17 years ago

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.

DarkShikari2• 17 years ago

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.

kelnos2• 17 years ago

If you read the article, it looks like Intel's CPU-type dispatcher actually does it the second way (sorta; it appears to only check Intel CPU family IDs), but at the bottom of that list there's a big "if(CPU string is not "GenuineIntel") { disable everything and use crappy fallback code path }".

wtallis2• 17 years ago

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.

jrockway• 17 years ago

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.)

rbanffy6• 17 years ago

Better yet: make it writable.

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

wmf4• 17 years ago

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

spicyj• 17 years ago

From the end of the article:

It is possible to change the CPUID of AMD processors by using the AMD virtualization instructions. I hope that somebody will volunteer to make a program for this purpose. This will make it easy for anybody to check if their benchmark is fair and to improve the performance of software compiled with the Intel compiler on AMD processors.

loudtiger• 17 years ago

sounds like the Pre and iTunes. haha.

dbz• 17 years ago

That idea is flawed because putting that string will make it optimize for an Intel chip, which will be worse than optimizing for an AMD chip because even though the compiler chooses the worst "optimized" option, it is still optimizing FOR that chip. -> The AMD optimization is optimized -But the Intel optimization is extra optimized (but not optimized for AM- only for itself).

djcapelis3• 17 years ago

Yes and no. I'm fairly certain that often the optimizations will be better than the fallback codepath in practice. This is especially true if you note that this is defeating the check for the vendor id, not defeating a lot of the other checks the dispatcher does.

pbhjpbhj2• 17 years ago

That would be passing off / trademark infringement FWIW.

pwmanagerdied• 17 years ago

No it wouldn't. All else aside, if this were the case every browser for the past decade would have been sued for including "Mozillla" and/or "MSIE" in their user-agent strings.

rbanffy6• 17 years ago

Isn't this the textbook reason for using - and contributing to - open-source compilers and libraries?

liuliu• 17 years ago

and gcc is not that bad after all. I uses openmp to parallel my program on core i7 860 cpu which should support 8-threads. But using icc as compiler, it will only utilize 7 cores, and it does affect performance (about 10% slower (wall time) than gcc which uses 8 cores). I suspect that it has something to do with the dynamic linked openmp library for icc.

jey2• 17 years ago

Really? I find Intel's compiler to outperform GCC on pretty much all of the numerical work I do. I build with "-O3 -xHost" and make use of OpenMP.

Dynamic linking of the OpenMP library is almost certainly not the cause of the slowness you're observing. If you really want to force the Intel OpenMP runtime to use all 8 cores:

  export OMP_DYNAMIC=false
  export OMP_NUM_THREADS=8
  export KMP_LIBRARY=throughput

  # "KMP_BLOCKTIME" is how long an idle worker thread
  # should enter a blocking wait for more work before
  # sleeping, in milliseconds. default value is 200ms
  export KMP_BLOCKTIME=1000

  # following are needed if you use Intel MKL
  export MKL_DYNAMIC=false
  export MKL_NUM_THREADS=8

For more info: http://software.intel.com/sites/products/documentation/hpc/c...

drewcrawford4• 17 years ago

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.

jimbokun• 17 years ago

"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."

I can't imagine Steve Jobs allowing this to happen at Apple. They have definitely caught people leaking things, and the consequences were swift and unpleasant for the leaker. Why can't AMD catch these people? Is there something preventing them from implementing the same kinds of measures to catch leakers as Apple?

(Using Apple just as an example, of course. I'm sure there are other companies who find leakers and make an example of them through the legal system.)

drewcrawford4• 17 years ago

There was one guy who was strung up as a leaker ten years ago. Don't remember his name, but it was a big deal.

AMD's culture is just different than Apple's. For one, there are no "secret teams" like iPhone, iTablet, etc. (well, at least none that I knew about). For another, developers have real autonomy to make business decisions, something that would never happen at Apple. For instance, I, a lowly intern, redeployed software to the production line during an emergency. If something went wrong, chips would actually stop rolling out of the factory. I would imagine normal (non-senior) Apple engineers don't have that kind of autonomy.

The other major difference, which perhaps you caught above, is that AMD actually manufactures their own stuff. So, not only are there US engineers, but engineers overseas in the plants that AMD owns, engineers in Dresden, etc. Not to say that foreign engineers are somehow bad, but it is a lot harder to control leaks when you have engineers working literally 24/7 all around the world. And at the scale that you're making your own stuff, there are just more people than there are at Apple, and things are way harder to control. It's like herding cats.

joe_the_user• 17 years ago

Well AMD is a small fraction of the size of Apple as well. Even more, Apple's business isn't oriented towards cutting into the market share of a large competitor. And there have been significant leaks at Apple.

rbanffy6• 17 years ago

The problem here is that you can easily detect leaks to the press. Tainted information gets published and you know who leaked by how the leak deviates from reality.

It's less so with leaks between companies. A company that deals this way will never allow the information it gathers to show up like that. Even analysts who will examine the leaked materials will have little (not so little in the case of Intel - they have like two competitors) information about the origins of what they are looking at.

praptak3• 17 years ago

"I can't imagine Steve Jobs allowing this to happen at Apple. They have definitely caught people leaking things, and the consequences were swift and unpleasant for the leaker."

Indeed, you don't wanna mess with Apple: http://news.cnet.com/8301-13579_3-10291701-37.html

brk4• 17 years ago

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.

Not sure what you mean by this statement. Should AMD get some sort of special consideration because they are smaller than Intel?

netcan3• 17 years ago

The point does not stand alone, you are right. drewcrawford said "If they try to specialize (say, servers, or notebooks), Intel will just sell that segment at a loss"

That's the point & that is arguably anticompetitive. IE, they are small and they have to spread wide to avoid being open to predatory pricing.

Andys2• 17 years ago

Sensational headline: this article is only about the Intel C Compiler, which as far as I can see, is only used for benchmarketing and research purposes.

scott_s2• 17 years ago

As a systems researcher, I have often used the Intel C Compiler when I wanted to make the most fair comparison possible because it is generally accepted to produce the best code of x86 processors. With that background, I correctly guessed from the headline what the content of the article was.

praptak3• 17 years ago

"Only" benchmarketing? If any published benchmarks are affected by this misfeature, it's pitchforks and torches for Intel.

Andys2• 17 years ago

Does it really come as news to anyone that if Intel wants to show their CPU in best light, they'll use their own compiler?

Caveat emptor.

The bulk of the x86 world uses Microsoft C++ or GCC - end of story.

herf• 17 years ago

When using IPP, I had to rewrite the CPU detector, even for new Intel chips as they came out. This code should be better...really it should just benchmark all the options and catch processor exceptions to pick a supported path.

Instead, the idea is to do a static dispatch for 'known' chips, which is really bad. When the Core2Duo came out, the version of IPP we used reverted to basic MMX code instead of SSE2, about 2.5x slower. This is just bad code, and it's bad on Intel chips, not just AMD.

Also there is the "optimized for benchmarking" piece. It's not always good to use all your cores for one job, for instance, but a lot of these libraries make the assumption that your CPU has nothing else to do.

wmf4• 17 years ago

Has anyone tried the Sun Studio compilers? They're free and supposed to be as good as Intel, but I've seen virtually no discussion of them.

daeken• 17 years ago

For x86, they fall behind a bit. For x64, they're faster than ICC in general. Definitely worth a look if you don't mind going to OSol.

jedbrown• 17 years ago

My experience on x64 has been that Sun is usually competitive with GCC/ICC, but not clearly better. Sun's C99 compiler does really atrocious things with SSE intrinsics, strange since their C++ compiler handles intrinsics almost as well as GCC/ICC. Note that they also work fine on Linux.

sfg• 17 years ago

I do not know much about processor benchmarking, but is it not a little weird that the bench markers use software that is not independent of the hardware they are testing? It seems like they are asking to be manipulated: why do they do this?

wmf4• 17 years ago

They think the software is processor-independent but it's really Intel-biased; that's the problem.

rythie2• 17 years ago

Not only should they fix it, they should open source the code, so AMD can contribute.

Intel often makes noises about open source, so they should put their money where there mouth is.

notauser• 17 years ago

Compiler discussion to one side for a minute...

Intel does more than just make noises about open source. Their wifi and graphics chip set support has been excellent over the years. Prior to the recent changes at ATI they were pretty much the only company doing that.

rythie2• 17 years ago

Agreed and it's good that they do that since I use their graphics and Wifi drivers on my Ubuntu Laptop.

My point was if they are truly committed to open source they would do this too, they are after all a hardware company and should compete by making the best hardware.

Intel's "cripple AMD" function

Related Stories