Live data from Hacker News

Intel's "cripple AMD" function (2009)

agner.org

101–110 of 131 posts

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

#101

At this point, does intel need that function to make AMD's CPU cores look bad?

AMD has 10-16 core server CPUs that are very price competitive with Intel's Xeon performance. They generate more heat however, so they are not economic in datacenters for energy usage reasons, but they are ideal for getting the most powerful workstation possible.

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

#102
post #96

Earlier quoted context omitted.

> This is not an acceptable use of trademarks. But if you were Intel, would you have your engineers work on competitors' products to make sure they are well supported on your line of tools? Before making an answer, consider that the core implementation of AMD cpus differ significanrly from those of Intel: instruction timings are slightly different, whether you look at them individually or in groups. It's not just a m…

Add another flag to the compiler to produce code optimized code for any CPU with the warning that it's only been verified to work with Intel CPUs. With todays CPU I do not buy the "safest path" argument - perhaps I could accept that "we only default enable it for implementations we have verified in-house", which makes a lot of sense. This sounds a lot more like Intel know they make the best compiler, and knowingly pu…

I guess they could do that, and trust that customers will always be reasonable to not sue them when in those situtations that they wanted to avoid. Besides, it's not 2009 anymore: if they want to maintain their arch on the market against ARM founders, they should probably help AMD out as much as possible (though I remember reading somewhere once that AMD considered including ARM cores in their APUs - or maybe it was just a journalist's speculation).

> This sounds a lot more like Intel [...]

Just a thought here: should Intel do things to avoid sounding like bad competitors, or to give their customers the best product they can offer? We're engineers, we should also know not to fall for appearances, shouldn't we? I know, I supported my own reasoning with the legal aspect of things, which sometimes is not very reasonable in what it must handle. There goes my original point.

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

#103

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.

That's interesting: could you elaborate on those problems? I was pretty much supporing Intel on the ground that their competitors products were just running a safe path, but your input might change my view entirely.

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

#104
post #86

Earlier quoted context omitted.

Intel is not the market leader in compilers, however: It is somewhat rare to come across teams using the Intel compiler, and they tend to be in niche modeling/simulation or financial realms, more often than not with the sort of code that you compile for a specific piece of deployment hardware, compiling again when you move it to something different. Intel makes the ICC seemingly to try to encourage the adoption of ne…

Have you ever seen benchmarks to suggest that Intel is not the market leader in compilers is actually true?

That comment was in relation to market share, not performance. Few would argue that Intel has more than a low single-digit percentage market share of the overall compiler market. People should be far, far more concerned about how GCC, llvm and Visual Studio do in vectorizing code to SSE/AVX.

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

#105
post #98
post #82

Earlier quoted context omitted.

Sure, but if merely switching compilers produced a faster binary, then I would expect all programs to be compiled with the better-optimizing compiler. After all, it doesn't take any particular expertise to adjust the value of CC.

There's more to optimization than setting -O3. Learning how various compilers behave and how their optimization features interact with your code are valuable skills and may well have been within the scope of the course. Certainly worthy of extra credit.

Sure, but why not mandate that everyone tunes the same compiler?...

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

#106
post #52

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…

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

It is relevant, if you consider that optimization isn't just counting cycles at individual instructions. Some optimization pass may be CPU agnostic (and the difference of performances between compilers on AMD probably show that aspect), and some very well depend on CPU peculiarities.

Also, if Intel must provide good support for all AMD chips, then they will have to do the same for any other competitor (and there are some iirc).

> they generate code that checks for an AMD CPU

Is it really what they do? Are they checking for "GenuineIntel" CPU, or for "AuthenticAMD" ones? There's a slight difference, even if AMD is their only real competitor atm.

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

#107
post #42
post #38

Earlier quoted context omitted.

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

A more effective place to put the notice would be to standard output when you're compiling for AMD.

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

#108

Earlier quoted context omitted.

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.

This, like almost every counter point I've faced thus far, is simply wrong . It is manufactured reality. ICC 8 added auto-vectorization. It, the very first auto-vectorization version, added the "GenuineIntel" branch for such vectorized code, because despite all of the fiction stated otherwise, vectorizing is actually a very hard task (hence why Intel maintains such a lead, and people are still griping about this 9 ye…

I don't understand your "because" statement. Intel added a check for Intel CPUs because vectorization is difficult. That's a complete non sequitur as far as I can tell. It makes as much sense as saying that I baked a chocolate cake because it rained yesterday.

Yes, various optimizations, including auto-vectorization, are difficult. Why does that mean Intel had to add a check for Intel CPUs in their compiler?

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

#109
post #60

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…

Technically, 8x faster is a 700% speedup.

Either way, using percentages there seems really misleading. 15% versus 700% (or 800%) looks like a much bigger difference than 1.15 versus 8 if you're not careful when thinking about it.

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

#110
post #98

Earlier quoted context omitted.

There's more to optimization than setting -O3. Learning how various compilers behave and how their optimization features interact with your code are valuable skills and may well have been within the scope of the course. Certainly worthy of extra credit.

Sure, but why not mandate that everyone tunes the same compiler?...

I'll flip the question around: why mandate it?

The class clearly has a performance component, and so students were expected to learn about optimization. Are they going to learn optimization better or worse if you mandate a single compiler? If merely switching compilers is the best path to performance, is that not a valuable lesson? If switching compilers and doing a bunch of extra work to make the code fast with the new compiler is the best path to performance, have they not learned a great deal?

Post reply on HN