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

Intel's "cripple AMD" function (2009)

agner.org

Post reply on HN
Print view View original

61–70 of 131 posts

Re: Intel's "cripple AMD" function (2009)

#61

Post by mikeash »

corresation wrote: post #59
mikeash wrote: post #52

Earlier quoted context omitted.

People have pointed out that the "Intel" code is faster than the "AMD" code even on AMD chips, so the stuff about performance being difficult to achieve across different CPUs, while true, does not seem to be relevant. All in all, you seem to be downplaying this far more than it deserves. It is not a case that the "compiler optimizes primarily for Intel processors". If it simply produced code built to be good on Intel…

Your first statement does not follow at all. Do people realize that we're talking very specifically about auto vectorization? This is a very unique, niche area of software (and it is absolutely an optimization, various hysterics notwithstanding), and this notion that various random software you're running are being "crippled" is utterly nonsensical.

I don't even understand what you're saying here.

We seem to be talking past each other, so let me briefly summarize what's going on, since you keep talking about optimizations and how difficult they are, and that just doesn't matter.

Intel's compiler produces multiple code paths, each one optimized for different CPU features.

The generated code always runs the slowest "fallback" code path on AMD CPUs.

Other code paths are still faster than the "fallback" path, even on AMD CPUs, despite not being optimized specifically for them.

Thus, Intel is artificially reducing the performance of their generated code on AMD CPUs. They put in more work to make this happen. If they had simply left out the CPU vendor check, AMD CPUs would perform better.

Re: Intel's "cripple AMD" function (2009)

#62

Post by corresation »

mikeash wrote: post #61
corresation wrote: post #59

Earlier quoted context omitted.

Your first statement does not follow at all. Do people realize that we're talking very specifically about auto vectorization? This is a very unique, niche area of software (and it is absolutely an optimization, various hysterics notwithstanding), and this notion that various random software you're running are being "crippled" is utterly nonsensical.

I don't even understand what you're saying here. We seem to be talking past each other, so let me briefly summarize what's going on, since you keep talking about optimizations and how difficult they are, and that just doesn't matter. Intel's compiler produces multiple code paths, each one optimized for different CPU features. The generated code always runs the slowest "fallback" code path on AMD CPUs. Other code path…

I stated that optimization is hard (each architecture has timings that impact when something is beneficial/when it isn't): Intel baked this into the ICC, but only for Intel targets (for obvious commercial reasons). You say that no, in some anecdote of apparently some anecdotal piece of code on some anecdotal set of data on some anecdotal AMD processor, this was disproven. But that doesn't disprove it in the general whatsoever. If Intel simply generated and ran Intel-targeted code always, we would have the same debate because why didn't they align their instructions and do it in such an order because that would be better on AMD.

It is entirely probable that simply running the "Intel" code chain will yield code slower than without on some sets of code with some sets of data, on some AMD architectures. Again, in most cases with vectorization you are not suddenly seeing a magnitude improvement, but rather something that can be marginal in some cases with some cases of data. It is a very hard problem, which is exactly why for all of the bluster the Intel Compiler is still considered the best compiler, 8 years into this controversy. AMD has been contributing to the Open64 compiler for years, but you don't hear much about it. And I'll bet their contributions don't put too much care into Intel processors.

Re: Intel's "cripple AMD" function (2009)

#63

Post by nitrogen »

corresation wrote: post #62
mikeash wrote: post #61

Earlier quoted context omitted.

I don't even understand what you're saying here. We seem to be talking past each other, so let me briefly summarize what's going on, since you keep talking about optimizations and how difficult they are, and that just doesn't matter. Intel's compiler produces multiple code paths, each one optimized for different CPU features. The generated code always runs the slowest "fallback" code path on AMD CPUs. Other code path…

I stated that optimization is hard (each architecture has timings that impact when something is beneficial/when it isn't): Intel baked this into the ICC, but only for Intel targets (for obvious commercial reasons). You say that no, in some anecdote of apparently some anecdotal piece of code on some anecdotal set of data on some anecdotal AMD processor, this was disproven. But that doesn't disprove it in the general w…

1. Old versions of icc ran well on AMD.

2. New icc version adds check for "GenuineIntel".

3. New icc version now runs slowly on AMD.

Re: Intel's "cripple AMD" function (2009)

#64

Post by Freaky »

agumonkey wrote: post #53
GhotiFish wrote: post #47

Earlier quoted context omitted.

What bothers me is that if a mainstream reviewer benchmarks ICC compiled programs, well, that isn't unfair. Real world programs are compiled with that compiler. AMD processors actually WILL under-perform on certain programs because of this. That leaves a bad taste in my mouth.

How much ICC compiled binaries represent ? I guess on MS Windows it's the vast majority so you're right[1] but on other platform it's probably GCC/Clang, and there neither Intel or AMD are favorited. [1] or maybe not ? are MS Cxx compilers inheriting from Intel ones ?

No, Microsoft make their own compilers.

Re: Intel's "cripple AMD" function (2009)

#65

Post by tharko »

lotyrin wrote: post #5
wmf wrote: post #3

(2009) Since then Intel settled the lawsuit by paying $10M and agreeing to add the following disclaimer to their compilers: "Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors..." http://software.intel.com/en-us/articles/optimization-notice... http://www.anandtech.com/show/3839/intel-settles-with-the-ft...

Yep, and that's been interpreted such that - just in case - we add a link on every page of software.intel.com to http://software.intel.com/en-us/articles/optimization-notice Whether or not the current page has anything to do with compilers. Also, judging by the URL they made it an 'article' instead of a 'page' again... I'll have to see if I can get someone to fix that.

The notice is only visible in Italian, Chinese, and Korean

Re: Intel's "cripple AMD" function (2009)

#66

Post by sitkack »

boyter wrote: post #54
salient wrote: post #33

Intel is one of the least ethical tech companies around. Have they even paid their 1 billion euro fine to the EU Commission yet for trying to force OEMs to not use AMD chips in their products? http://www.engadget.com/2009/05/13/intel-fined-1-45-billion-...

I wouldn't be surprised if they had. Off the top of my head they made over $7 billion doing this and can consider the fine as a cost of doing business.

When companies do this, they should be fully audited and fined 300% profit, split evenly between the harmed company and the government. If that puts them out of business, so be it.

Re: Intel's "cripple AMD" function (2009)

#67

Post by sitkack »

fnimick wrote: post #46
mikeash wrote: post #41

Earlier quoted context omitted.

To make an obligatory car analogy, imagine if Ford opened up gas stations that sold really good gas, but this gas was somehow made to run much less efficiently in non-Ford cars. And further that they didn't tell anyone this, and just left you to assume that if you filled up your Prius with Ford gas and subsequently got 20MPG, the car was to blame.

It's even worse than that - since companies are distributing binaries compiled with icc, it's more like a Ford gas refinery distributing gas to normal gas stations that secretly runs terribly in other cars. There simply is no way for the consumer to know what they're getting.

This nock on effect is where the real harm is done. The fact that Intel is not checking for feature flags, but rather the existence of an Intel processor is actionable. They aren't following their own best practices for accessing optional features of the chip.

Re: Intel's "cripple AMD" function (2009)

#68

Post by dchichkov »

neurostimulant wrote: post #27
dchichkov wrote: post #11

I've ran into it in practice a few years back, while making WRF (math intensive atmospheric modeling software, I'm maintaining non-commercial soaring prediction site for the bay area) to work on my AMD cluster. Had to patch the executable compiled with the Intel compiler in order to make it work unhindered on AMD's. The patch was just zapping 'Genuine Intel' detection code in the compiled executable... That 'post-lin…

Why not just recompile wrf from source? Dependency hell?

Er, I was building it from source... Don't remember exactly was blocking me from using GCC, vaguely remember something about OpenMP support... The config in question was MPI+OpenMP, where OpenMP was used to parallelize withing a node of a cluster and MPI for the cluster itself.

Re: Intel's "cripple AMD" function (2009)

#69

Post by mikeash »

corresation wrote: post #62
mikeash wrote: post #61

Earlier quoted context omitted.

I don't even understand what you're saying here. We seem to be talking past each other, so let me briefly summarize what's going on, since you keep talking about optimizations and how difficult they are, and that just doesn't matter. Intel's compiler produces multiple code paths, each one optimized for different CPU features. The generated code always runs the slowest "fallback" code path on AMD CPUs. Other code path…

I stated that optimization is hard (each architecture has timings that impact when something is beneficial/when it isn't): Intel baked this into the ICC, but only for Intel targets (for obvious commercial reasons). You say that no, in some anecdote of apparently some anecdotal piece of code on some anecdotal set of data on some anecdotal AMD processor, this was disproven. But that doesn't disprove it in the general w…

"If Intel simply generated and ran Intel-targeted code always, we would have the same debate because why didn't they align their instructions and do it in such an order because that would be better on AMD."

That same debate might happen. But I doubt we'd see it, because most people would dismiss such a debate as stupid. Why would Intel put any effort into making their compiler optimize code for AMD CPUs?

Again: there is a world of difference between simply not optimizing for AMD, and deliberately running slow code when an AMD CPU is detected.

If Intel just checked CPU features and decided based on that, would it still produce bad code for AMD sometimes? Probably. Would it be as slow? Doesn't sound like it, from people with real-world experience with the compilers. Would people still complain? Yes. Would those complaints have any merit? No.

Re: Intel's "cripple AMD" function (2009)

#70

Post by welterde »

salient wrote: post #33

Intel is one of the least ethical tech companies around. Have they even paid their 1 billion euro fine to the EU Commission yet for trying to force OEMs to not use AMD chips in their products? http://www.engadget.com/2009/05/13/intel-fined-1-45-billion-...

There is plenty of space to the bottom though.. Intel at least publishes datasheets, technical documentation, etc. without requiring signing a NDA for most of their chips..

So in my books they still do quite a bit better than Broadcom, Realtek, etc.

Post reply on HN