Are Intel compilers really better than the Microsoft ones? [closed]

Question

Years ago, I was surprised when I discovered that Intel sells Visual Studio compatible compilers. I tried it in particular for C/C++ as well as fantastic diagnostic tools. But the code was simply not that computationally intensive to notice the difference. The only impression was: did Intel really do it for me just now, wow, amazing tools with nanoseconds resolution, unbelievable. But the trial ended and the team never seriously considered a purchase.

From your experience, if license cost does not matter, which vendor is the winner?

It is not a broad or vague question or attemt to spark a holy war. This sort of question is about two very visible tools. Nobody likes when tools have any mysteries or surprises. And choices between best and best are always the pain. I also understand the grass is always greener argument. I want to hear all "what ifs" stories.

What if Intel just locally optimizes it for the chip stepping of the month, and not every hardware target will actually work as well as Microsoft compiled? What if AMD hardware is the target and everything will slow down for no reason? Or on the other hand, what if Intel's hardware has so many unnoticable opportunities, that Microsoft compiler writers are too slow to adopt and never implement it in the compiler? What if both are the same exactly, actually a single codebase just wrapped into two different boxes and licensed to both vendors by some third-party shop?

And so on. But someone knows some answers.

Answer 1

WARNING: Answer based on own experience - YMMV

If the code is really computationally expensive, yes, definitely. I have seen an improvement of over 20x times with the former Intel C++ Compiler (now Intel Studio if I recall correctly) vs the standard Microsoft Visual C++ Compiler. It's true the code was very far from perfect and that may have played a role (actually that's why we bothered using the Intel compiler, it was easier than refactoring the giant codebase), also the CPU used to run the code was an Intel Core 2 Quad, which is the perfect CPU for such a thing, but the results were shocking. The compiler itself contains myriads of ways to optimize code, including targeting a specific CPU in terms of, say, SSE capabilities. It really makes -O2/-O3 run away ashamed. And that was before using the profiler.

Note that, however, turning on really aggressive optimizations will make the compilation take quite some time, two hours for a large project is not impossible at all. Also, with high levels of optimizations, there's a higher chance of an error in the code to manifest itself (this can be observed with gcc -O3, too). To a project you know well, this might be a plus, since you'll find and fix any eventual bugs you didn't catch earlier, but when compiling a hairy mess, you just cross your fingers and pray to the x86 gods.

Something about performance on AMD machines: It's not as good as Intel CPUs, but it's still way better than the MS C++ compiler (again, from my experience). The reason is that you can also target a generic CPU with SSE2 support (for example). Then AMD CPUs with SSE2 will not be discriminated much. Intel compiler on Intel CPU really steals the show, though. It's not all double rainbows and shiny unicorns, however. There have been some heavy accusations about binaries not-running at all on non-GenuineIntel CPUs and (this one is admitted) artificially induced inferior performance on CPUs by other vendors. Also note this is information from at least 3 years ago and it's validity as of now is unknown, BUT the new product descriptions gives binaries a carte blanche to run as slow as Intel sees fit on non-Intel CPUs.

I don't know what it is about Intel and why they make so good numeric computation tools, but have a look at this, too: http://julialang.org/. There is a comparison and if you look at the last row, MATLAB shines by defeating both C code and Julia, what strikes me is that the authors think the reason is Intel's Math Kernel Library.

I realize this sounds a lot like an advertisement for the Intel Compiler toolkit, but in my experience it really did the job well, and even simple logic dictates that the guys who make CPUs should know best how to program for them. IMO, the Intel C++ compiler squeezes every last bit of performance gain possible.

Answer 2

Intel Compiler has a reputation of producing very efficient numerical code:

https://stackoverflow.com/questions/1733627/anyone-here-has-benchmarked-intel-c-compiler-and-gcc

http://www.open-mag.com/754088105111.htm

http://www.freewebs.com/godaves/javabench_revisited/

Please note that I don't claim that it is the fastest compiler out there, but it certainly enjoys a very good reputation for efficiency. Note that the authors of "official" LAPACK binaries for Windows use the Intel Fortran compiler to build them: http://icl.cs.utk.edu/lapack-for-windows/ and they should know a thing or two about efficiency.

Answer 3

Intel C++ has a couple of advantages over gcc in addition to the code generator. Both of these stem (largely) from the fact that it's based on the EDG front-end. For better or worse, both of these are (slowly) eroding, so the advantages aren't nearly as great as they once were.

The first is that it issues much better error messages as a rule. You might want to look at a comparison of error messages between Clang and gcc. Intel C++ (along with most others based on the EDG front-end) has been issuing diagnostics similar to Clang's for years.

Second, is that the EDG front end is about as well known for exceptionally good language conformance as the Intel code generator is for producing fast code. By almost any reasonable measure, the EDG front-end provides better conformance with C++98, 03, or (in current versions) C++0x than any other compiler available.

As I said, both of these advantages have eroded to varying degrees over time. Recent versions of gcc have pretty decent language conformance. Clang has substantially better error messages, and is making good progress toward implementing the entire C++ language as well. When you get right down to it, however, Intel C++ is still better than either one in both regards, and it's a single package that does most things right instead of needing one compiler for good diagnostics and another for better conformance and code generation.

Answer 4

We tried this at work a while back. Most of our codebase is in Delphi, but we've got some highly computationally-intensive functionality that someone thought would be a good idea to do in a C++ DLL way back when. And one of my coworkers had heard great things about the Intel compiler, so he decided to try it out. We rebuilt the DLL in the Intel compiler and ran some speed tests, and the results surprised him so much that he figured he must be doing something wrong.

The DLL has to calculate some very difficult problems with combinatorics and topology components, which are technically in the NP-hard difficulty class if we did them "right", but we use various heuristics to avoid NP performance. Even so, there's a lot of number crunching going on. And for the tests we ran, the difference between the VS compiler and the Intel compiler was either within epsilon, or the Intel compiler was noticeably slower, generally by somewhere in the neighborhood of 20%. And it stayed like that no matter what changes he made to the compile settings to try to get the Intel compiler to produce faster code. So we ended up not switching to it.

This is only one real-world example, of course. Your mileage may vary.

Answer 5

In an embedded application I once worked on, a trial of an Intel compiler showed it would save us having to spin new hardware with higher performance. The cost of the new hardware was around $10/unit, projected sales of 1 Million units, Add development cost and project delays. Option 2 was a profile/micro optimize an already reasonably well profiled/optimized code base - unknown results, unknown time.

What do you think the boss said when we asked for the funds to buy the compiler.......

However - this was a very lucky and rarer edge case - the 10% faster code output from the Intel compiler pushed us back onto the correct side of performance. If we were already on the right side, or were 10% over, it would not have made a difference. Had we had the engineers we probably could have optimized the code and saved the hardware spin and not needed the Intel compiler, But the risk was high and the Intel compiler worked out cheaper than the engineering time.

On balance I would say it is a form of micro optimization - don't do it till you know you need to, and then, only after you have profiled and found the actual cause of the problems. It is a a particularly good choice of you profile shows you are slow 'everywhere' and have no identified bottle necks.

Answer 6

I've only encountered three advantages:

1. It has support for features of newer Intel CPUs much sooner than other compilers do.

2. It's a great additional compiler to issue warnings and catch problems that other compilers miss. GCC catches some things ICC doesn't, and vice versa. Visual studio catches some things ICC doesn't, and vice versa.

3. It does a much better job of auto-parallelizing loops (distributing them over multiple threads automatically) than any other compiler. Not very much code benefits from this, but when you have code that does, it can make a heck of a difference.

Answer 7

We use the intel compiler for every performance critial project of our codebase. The great thing about it is, it makes optimizing code really maintainable. Instead of manually adding __mm calls everywhere, and telling the compiler to prefetch data, all of which will be sub optimal in the next release again, you just rearrange your code some and gain an insane speedup.

Often, the optimized code is easier to follow than the hand optimized, it's faster than the hand optimized, and when a new instruction set are release, the compiler will use that instruction set. It's fantastic.

The same also goes for the arm compiler (from arm, not intel), if your releasing on arm, does a great job in vectorizing for you.

Answer 8

Check this benchmark page. In short, intel wins.

But the margin may not be that big: if you compile to 32 bit, and your build system cant support profile guided optimization, the gain is of the order of 10%. Is such an improvement worth the trouble and the longer compile times?

Answer 9

It's been said that Intel has released the Intel C++ Compiler v13.0 for Android OS, its first attempt at delivering an optimizing C/C++ compiler designed specifically for Google's mobile platform.

Developers can use the compiler on Linux*-based systems to create apps for Android devices based on Intel processors, including the Intel® Atom™ processor. The Intel compiler is compatible with GNU C++ and developer tools in the Android Native Development Kit (NDK) You can't use the compiler on just any development machine, either. Neither Windows nor OS X is supported; the tools are only certified for use with Ubuntu 10.04 or 11.04

The current version of the Android NDK uses version 4.6 of the open source Gnu Compiler Collection (GCC) toolchain by default. But Intel's compilers include lots of proprietary optimizations for its own chips, and can often output executable code that performs better than that produced by third-party compilers such as GCC.