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

71–80 of 131 posts

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

#71

Post by raverbashing »

sounds wrote: post #60
moconnor wrote: post #45

Earlier quoted context omitted.

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…

"Hand-optimized code: 800% speedup"

It really depends.

Especially in how naively the "non-optimized" code was written.

I can see vectorization accelerate from 2x to 4x (per core), but not much more than that (which the Intel compiler does best)

But even GCC can vectorize better today than in the early days of 4.0

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

#72

Post by sounds »

raverbashing wrote: post #71
sounds wrote: post #60

Earlier quoted context omitted.

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…

"Hand-optimized code: 800% speedup" It really depends. Especially in how naively the "non-optimized" code was written. I can see vectorization accelerate from 2x to 4x (per core), but not much more than that (which the Intel compiler does best) But even GCC can vectorize better today than in the early days of 4.0

Sure, it depends. I've seen embarrassingly parallel (yeah, that's a real term) code with speedups in the 20's.

My personal best was a 9x speedup, partly by using SSSE3 and partly by some really good prefetching and non-temporal writes.

If you look at what I said in the very narrowest light, I agree that SSE2 all by itself typically delivers a 2x speedup per core over non-SSE code.

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

#73

Post by lotyrin »

shocks wrote: post #50
lotyrin wrote: post #5

Earlier quoted context omitted.

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

Not sure, more likely somebody got a zip file full of images from the lawyer(s) and decided to put those up exactly as provided.

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

#74

Post by sounds »

sitkack wrote: post #66
boyter wrote: post #54

Earlier quoted context omitted.

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.

That would certainly discourage _getting caught_ violating the law.

It would also tend to kill off the older companies (weak law of large numbers: if a company violates any of the laws that will kill it, and it exists long enough, it eventually gets caught and killed).

It might even lead to some efforts at counter-legislation. For example, companies might lobby to _broaden_ the "get killed" legislation, which would result in lots of sympathy cases where companies were killed for "minor" offenses. Eventually the whole "kill the company" idea would fall out of favor.

http://en.wikipedia.org/wiki/Three-strikes_law

(Companies will tend to view a government audit as a death sentence, since it would damage them so much even without a 300% fine.)

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

#75

Post by makomk »

berkut wrote: post #51
staticfish wrote: post #12

Earlier quoted context omitted.

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…

Except it turns out not to work that way - most of the optimisations turn out to be general ones, and some of the non-optimised code paths AMD gets for stuff like string copying are slower than a naive implementation. (Actually, Intel wound up having to fudge the CPUID result on their newer processors for this reason. Otherwise binaries compiled on their older compilers would detect an unrecognised chip and run the slow path - including some of the benchmarkers reviewers would use to compare the two!)

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

#76

Post by eridius »

nanidin wrote: post #57
aylons wrote: post #30

Earlier quoted context omitted.

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.

You were graded based on compiled binaries that you provided, and not based on the source? That sounds crazy to me.

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

#77

Post by nanidin »

eridius wrote: post #76
nanidin wrote: post #57

Earlier quoted context omitted.

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.

You were graded based on compiled binaries that you provided, and not based on the source? That sounds crazy to me.

We provided build scripts and source. The extra credit was for fastest execution time.

I assume you're payed based on final results, not based on source. Not so crazy of a concept - whoever delivered the best results got rewarded for it.

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

#78

Post by nkurz »

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…

Just to join the chorus: it's not a hard problem. Intel intentionally adds code to the executables produced by their compiler so as to limit their performance on non-Intel CPUs. They lost a federal lawsuit filed by the FCC on deceptive practices because they did not inform their customers, who thought they were buying a working compiler, that they were doing this.

Instead of simply removing this code, which serves no purpose other than degrade performance on non-Intel CPUs, they reached an agreement to put legal disclaimers on every web page mentioning their compiler that they reserve the right to do this. But because of the slick legal language of the disclosure, most people get the impression that they are simply failing to make AMD specific optimizations, rather than intentionally preventing non-Intel CPUs from utilizing the optimizations already present in the code.

I think we all agree that at this point Intel's practice is fully legal. Their engineers should feel proud of having built a really solid compiler. But Intel-the-company deserves to be shamed for its slimy underhanded practices, and the engineers should feel a certain amount of revulsion for allowing themselves to be used in this way. Perhaps if they stood up for the obvious right approach, they could help change the company for the better.

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

#79

Post by userbinator »

welterde wrote: post #70
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.

I agree, although Intel is still not as open as they were back in the e.g. 8086 days - stuff related to the BIOS/memory controller init sequence is still AFAIK requiring NDA.

Better than AMD, at least - just try finding the pinout of socket AM2, which was released over 7 years ago.

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

#80

Post by gcb0 »

nanidin wrote: post #77
eridius wrote: post #76

Earlier quoted context omitted.

You were graded based on compiled binaries that you provided, and not based on the source? That sounds crazy to me.

We provided build scripts and source. The extra credit was for fastest execution time. I assume you're payed based on final results, not based on source. Not so crazy of a concept - whoever delivered the best results got rewarded for it.

luckily for you your professor did not have an AMD cpu...
Post reply on HN