At this point, does intel need that function to make AMD's CPU cores look bad?
Intel's "cripple AMD" function (2009)
101–110 of 131 posts
Re: Intel's "cripple AMD" function (2009)
#102Earlier 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…
> 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)
#103When 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)
#104Earlier 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?
Re: Intel's "cripple AMD" function (2009)
#105Earlier 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.
Re: Intel's "cripple AMD" function (2009)
#106Earlier 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…
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)
#107Earlier 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).
Re: Intel's "cripple AMD" function (2009)
#108Earlier 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…
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)
#109Earlier 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…
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)
#110Earlier 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?...
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?