How much should I worry about the Intel C++ compiler emitting suboptimal code for AMD?

Question

We\'ve always been an Intel shop. All the developers use Intel machines, recommended platform for end users is Intel, and if end users want to run on AMD it\'s their lookou

Answer 1

Buy an AMD box and run it on that. That seems like the only responsible thing to do, rather than trusting strangers on the internet ;)

Apart from that, I believe part of AMD's lawsuit against Intel is based on the claim that Intel's compiler specifically produces code that runs inefficiently on AMD processors. I don't know whether that's true or not, but AMD seems to believe so.

But even if they don't willfully do that, there's no doubt that Intel's compiler optimizes specifically for Intel processors and nothing else.

When that is said, I doubt it'd make a huge difference. AMD CPU's would still benefit from all the auto-vectorization and other clever features of the compiler.

Answer 2

It's pointless to worry if you can't act. Possible actions are: Not buying AMD, or using a different compiler. So the obvious things to do are:

(1) Buy one AMD box, and measure the speed of the code compiled with the Intel compiler. Is it fast enough? If yes, you're done, you can buy AMD, don't worry.

(2) If no: Compile the code with a different compiler and run it on the AMD box. Is it fast enough? If no, you're done, you can't buy AMD, don't worry.

(3) If yes: Run the same code on an Intel box. Is it fast enough? If yes, you're done, you can buy AMD but have to switch compilers, don't worry.

(4) If no: Possibilities are: Don't buy AMD, throw all Intel computers out, or compile with two different compilers. Pick one.

Answer 3

At the time this thread was started, Microsoft C++ defaulted to code generation which was good in some cases for AMD and bad for Intel. Their more recent compilers default to the blend option which is good for both, particularly after both brands of CPUs had worked out their peculiar performance bugs. When I first worked at Intel, their compilers reserved some optimizations for Intel-specific architecture settings. I guess that might have been a topic of some FTC depositions, although it didn't come up in my 10 hours of testimony, and the practice was already on the way out due to convergence of optimization requirements between up to date CPU models and the need for more productive use of compiler development time. If you used one of those obsolete compilers on an up to date Intel CPU, you might see some of the same performance deficiencies.

Answer 4

I have directly experienced purposeful crippling of technology when a vendor attempted to prevent a Lotus product from reaching market before their offering. A working technology was available, but Lotus was forbidden to use it. Ah well...

A few years back there were blogs that showed users that patching a single byte in the Intel compiler caused it to emit "optimal" code that was not crippled when used on AMD. I have not looked for those blog entries in years.

I am inclined to believe that such competitive behavior continues. I have no other evidence to offer.

Answer 5

I'm surely stating the obvious, if performance is crucial for your application, then you'd better do some testing - on all combinations of hardware/compiler. There are no guarantees. As outsiders, we can only give you our guesses/biases. Your software may have unique characteristics that are unlike what we've seen.

My experience:

I used to work at Intel, and developed an in-house (C++) application where performance was critical. We tried to use Intel's C++ compiler, and it always under performed gcc - even after doing profile runs, recompiling using the profiled information (which icc supposedly uses to optimize) and re-running on the exact same dataset (this was in 2005-2007, things may be different now). So, based on my experience, you might want to try gcc (in addition to icc and MSVC), it's possible you will get better performance that way and side-step the question. It shouldn't be too hard to switch compilers (if your build process is reasonable).

Now I work at a different company, and the IT folks do extensive hardware testing, and for a while Intel and AMD hardware was relatively comparable, but the latest generation of Intel hardware significantly out-performed the AMD. As a result, I believe they purchased significant amounts of Intel CPUs and recommend the same for our customers who run our software.

But, back to the question as to whether the Intel compiler specifically targets AMD hardware to run slowly. I doubt Intel bothers with that. It could be that certain optimizations that use knowledge about the internals of Intel CPU architecture or chipsets could run slower on AMD hardware, but I doubt they specifically target AMD hardware.

Answer 6

What we have seen is that wherever the Intel compiler must make a runtime choice about the available instruction set, if it does not recognize an Intel CPU, it goes in their "standard" code (which, as you might expect, may not be optimal).

Note that even if I used the word "compiler" above, this mainly happens in their supplied (pre-compiled) libraries and intrinsics that check the instruction set and call the best code.