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

51–60 of 131 posts

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

#51

Post by berkut »

staticfish wrote: post #12
w1ntermute wrote: post #7

Can you spoof AMD CPUs to return "GenuineIntel" instead of "AuthenticAMD"?

Couldn't that also potentially break some logic branch through the chip where the app is expected to be running on a GenuineIntel processor? I'm not well versed in this.

Possibly, as Intel's compiler uses dynamic code-path selection based on the processor.

But more likely, it would mean slower code execution, as the code path wouldn't be optimised for AMD:

i.e. if the processor check thinks it's running an i7 Sandy Bridge, with an SSE float divide latency of 11, but the AMD chip has a latency of 23, so the unrolled loop that worked well for the i7 doesn't work at all for the AMD chip.

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

#52

Post by mikeash »

corresation wrote: post #48
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.

That analogy worked in 2005, but eight years on the fact that the Intel compiler optimizes primarily for Intel processors is common knowledge, and is explicitly stated by Intel repeatedly on all product materials. Invariably someone will bring up the "but what about benchmarks corrupted by this compiler" conspiracies, without a single example of a benchmark so contrived. It's worth noting that performance and process…

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 and with no attention paid to AMD CPUs at all, that would be fine. Nobody would complain. Nobody would expect anything else, really. But that's not what they do: instead, they generate code that checks for an AMD CPU and then deliberately chooses a suboptimal path in that case. So it's not a case of "optimizes primarily for Intel processors", but rather "intentionally cripples performance on non-Intel processors". That is to say, there is a vast gulf between indifference and purposefully making things worse.

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

#53

Post by agumonkey »

GhotiFish wrote: post #47
agumonkey wrote: post #15

Bothered me when I realized that maybe mainstream reviews (the ones able influence the average mass market buyer) were using binaries very biased in favor of intel.

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 ?

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

#54

Post by boyter »

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.

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

#55

Post by wmf »

GhotiFish wrote: post #47
agumonkey wrote: post #15

Bothered me when I realized that maybe mainstream reviews (the ones able influence the average mass market buyer) were using binaries very biased in favor of intel.

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.

Maybe any program compiled with ICC should have the same disclaimer as ICC itself so people know that the program is biased.

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

#56

Post by coldcode »

When I worked for a game company we used the Intel compiler for a couple of versions but it caused so many issues for people with AMD we switched back to the MS compiler. In the end the performance difference wasn't enough to matter.

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

#57

Post by nanidin »

aylons wrote: post #30
neurostimulant wrote: post #27

Earlier quoted context omitted.

Why not just recompile wrf from source? Dependency hell?

Probably it wouldn't work so nice with other compiler. This level of optimization often requires compiler - specific syntax. Not to say Intel optimization is really good.

I was in a parallel programming class where the fastest correct assignments got significant extra credit boosts. Compiling with the intel compiler with optimizations turned on (vs gcc) was often enough to make the difference in getting that extra credit by a significant margin.

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

#58

Post by agumonkey »

JohnBooty wrote: post #37
salient wrote: post #35

Earlier quoted context omitted.

I don't think that's been their motto since Otellini took over. Look where they are now in the mobile market. Otellini put the profitability of their Core chips above improving Atom in the first few years, even when it came to netbook performance, which was already terrible. Combined with the fact that they forced OEMs to not buy AMD alternatives during the same time, Otellini just didn't think it's necessary to impr…

They only started caring about power consumption when it was already obvious to everyone that ARM is going to pose a threat to them eventually. I'm being a bit pedantic, but it seems to me they refocused on power consumption beginning with the launch of the Pentium M (forerunner of the Core and Core 2 lines) which was released in 2003 and was surely in development several years before that. Or do you think they were…

That's true, the NetBurst syncope made them redesign toward efficiency, but still, the rise of ubiquitous mobility forced another inflection in their TDP curve. And they're still sweating over it since the PC market is shrinking and they need to get their foot in the smartphone/tablet market (see the bay-trail subsidize effort http://liliputing.com/2014/01/bay-trail-tablets-cheap-intels...)

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

#59

Post by corresation »

mikeash wrote: post #52
corresation wrote: post #48

Earlier quoted context omitted.

That analogy worked in 2005, but eight years on the fact that the Intel compiler optimizes primarily for Intel processors is common knowledge, and is explicitly stated by Intel repeatedly on all product materials. Invariably someone will bring up the "but what about benchmarks corrupted by this compiler" conspiracies, without a single example of a benchmark so contrived. It's worth noting that performance and process…

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.

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

#60

Post by sounds »

moconnor wrote: post #45
TwoBit wrote: post #6

How does the Intel compiler compare to others today? We tried using it for game development years ago and it had too many problems to make it worthwhile (e.g. pathological behavior with some C++ code).

The Intel compiler is extremely good at finding and exploiting vectorization (SSE/AVX) opportunities; using these instructions in hot loops is becoming key to getting anywhere near peak performance out of modern CPUs. Most people don't care enough about performance to notice, but recompiling with Intel's compiler often shows a 5-15% difference on number crunching codes and that's before spending time investigating th…

Just in case you skimmed moconnor's comment, it bears repeating:

Intel's compiler: 15% speedup

Hand-optimized code: 800% speedup

This gap in compiler tech is still a big deal today. Think about the early mainframes and how the code was all written in machine code or assembler. http://www.pbm.com/~lindahl/mel.html

Compilers can still improve, a lot.

• Parallel code? _still_ hand-written, even though choosing the right language/library can help. Note that choosing that language that makes parallelism easy may cost you when you actually go for the max parallel speedup

• GPU? hand-written. See: litecoin miners and bitcoin miners before that. OpenCL but were hand-tuned for a specific architecture

• Cross-platform? Java and C should be portable, but ask any Android developer how it really works

• And the one we're talking about here: number-crunching code? hand optimized!

I'm actually quite optimistic about the future of compilers. One of the reasons HN is so fun to read is that it comes up often.

Post reply on HN