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

41–50 of 131 posts

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

#41

Post by mikeash »

wmf wrote: post #31
aeonsky wrote: post #28

Earlier quoted context omitted.

I am usually not a free market extremist, but if Intel makes an excellent software product after years and millions of dollars in R&D, and make it only work for certain platforms, power to them.

The problem is that they penalized AMD without telling anyone. The market only works if you know what you're buying.

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.

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

#42

Post by fnimick »

gwern wrote: post #38
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...

> Since then Intel settled the lawsuit by paying $10M and agreeing to add the following disclaimer to their compilers Is it just me or does that not actually fix the problem?

It fixes the legal problem. Intel isn't required to provide an optimized compiler for competitors' chips, but it is required to note that its compiler that is compatible with those chips doesn't optimize code for them.

I don't agree either, but it's a perfectly valid solution (and probably the best for Intel's bottom line).

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

#44

Post by stephencanon »

bd_at_rivenhill wrote: post #21

This all seems to indicate that the intel compiler emits multiple, cpu-dependant code paths for a given binary, which seems insane to me due to the amount of extra memory that this would require. Am I missing something here?

Extra code on disk doesn’t cost anything (well disk space, but that is “free” for practical purposes). A compiler can arrange so that all of the code for a given architecture appeared consecutively in the binary, and then the pages and cachelines containing implementations unused by the processor on which you are running are never loaded into memory / never take up space in the cache.

Also, in practice code is a tiny portion of the size of a typical application. Far more space is consumed by resources like images and sounds.

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

#45

Post by moconnor »

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 the vectorization output and fine-tuning.

On the other hand, if you really care about speed then someone with some experience in performance tuning will typically be able to make your code run 4-8x faster, vastly outweighing any benefits from the compiler.

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

#46

Post by fnimick »

mikeash wrote: post #41
wmf wrote: post #31

Earlier quoted context omitted.

The problem is that they penalized AMD without telling anyone. The market only works if you know what you're buying.

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.

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

#47

Post by GhotiFish »

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.

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

#48

Post by corresation »

mikeash wrote: post #41
wmf wrote: post #31

Earlier quoted context omitted.

The problem is that they penalized AMD without telling anyone. The market only works if you know what you're buying.

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 processors isn't as simple as "it has the feature, so use it". Each instructions have timings that vary on different models, and something like SSE(2|3|4) or AVX(2|512) can vary dramatically in its net benefit or detriment by the number of words, alignment, and so on. Many people with the ICC and code that they think will be super fast using it often are surprised to find it hasn't chosen to use them at all, simple setup and teardown eating all possible benefit.

In an ideal world we would have an open compilers that made best in class code for all major processors. Sadly that doesn't exist, and even now we have a case where a lot of the complaints about the ICC are "it crippled the code for my AMD....but still made better code than every other compiler".

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

#49

Post by berkut »

gwern wrote: post #38
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...

> Since then Intel settled the lawsuit by paying $10M and agreeing to add the following disclaimer to their compilers Is it just me or does that not actually fix the problem?

There are several benchmarks out there showing that the Intel compiler can give a boost for AMD chips over MS VC++ and MingG++ on Windows.

They should have originally used supported flags for different features instead of blacklisting the name, but it's still difficult to know what chips support what and whether it's worth using those features, due to different instruction latency, etc.

ICC get register dynamic code switching to different paths in the exe, so that if the chip supports AVX2, it'll use that code path.

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

#50

Post by shocks »

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.

I presume the notices are images so they can't be indexed by search engines?...
Post reply on HN