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.

  • 17
    Intel Compilers have a reputation for producting very efficient numerical code.
    – quant_dev
    Commented Aug 4, 2011 at 15:51
  • 2
    @honk: If quant_dev can provide some links to back that up, then yes it should be! Commented Aug 4, 2011 at 16:13
  • 2
    @RocketSurgeon: Not everyone would agree with your statement. In fact Eric Raymond makes a pretty strong case for Microsoft having held the progress of computing back by a few decades with their business practices. Commented Jun 4, 2012 at 22:43
  • 2
    @RocketSurgeon open source has nothing to do with money.
    – kaoD
    Commented Jun 5, 2012 at 1:13
  • 1
    Microsoft compiler generates very good code. Manual inspection of the assembly rarely finds any idiotic instruction sequences. In fact, I was impressed how deep the optimizations go, it even prevents instructions from crossing cache line boundaries.
    – doug65536
    Commented Dec 27, 2012 at 1:00

9 Answers 9


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.

  • @K.Steff Did you compare this vs ms compiler with whole program opt and profile guided optimization.
    – rerun
    Commented Apr 29, 2013 at 21:13
  • 3
    Intel was forced to disclose that their compiler deliberately uses unoptimized code paths at runtime if the CPU is not manufactured by Intel. Intel got into trouble with the FTC. You couldn't pay me to use ICC. I wouldn't touch that anti-competitive piece of crap with a 10 foot pole.
    – doug65536
    Commented Apr 22, 2016 at 12:49
  • 2
    @doug65536 The question that is asked is "Are Intel compilers really better", not "Is Intel a monopolist in the hardware market that abuses this monopoly to further gain grounds in software". I'm not saying your comment is offtopic, but for me ideology has no place in this discussion. Use or not - your call, but that won't change the fact that ICC is pretty damn good at producing binaries for Intel CPUs.
    – K.Steff
    Commented May 25, 2016 at 9:32
  • The C language which became popular in the 1990s extended the C language in many ways that allowed programmers to write more efficient code, but which some optimizing compilers do not support. Microsoft has from what I can tell been less eager than other vendors to pursue optimizations that would be incompatible with such extensions. This makes their compilers less efficient than those which don't care about such compatibility when processing code that doesn't require them, but allows it to correctly processes code that does require them.
    – supercat
    Commented Jun 27, 2016 at 0:07

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




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.

  • 2
    Not only does it have that reputation, it lives up to it. It's not necessary if you're using it to write CRUD applications, but the C, C++ and FORTRAN products absolutely rawk when it comes to number crunching.
    – Blrfl
    Commented Aug 4, 2011 at 17:53

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.


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.

  • Would you mind sharing the details of the CPU the benchmarks ran on?
    – Oak
    Commented Jun 3, 2012 at 13:05
  • 23
    When I read your first paragraph, I thought you were saying that the speed test results surprised him in a good way. Apparently that's wrong, after having read the second paragraph. Not sure what mislead me on the first reading; upon closer inspection, you don't actually use any positive words that could have left me with that perception. Just thought I'd comment in case anyone else makes that same mistake and is confused about what you're actually saying here. Commented Jun 3, 2012 at 13:06
  • 2
    Were you using an AMD processor for the testing? I think it's relevant information (whether the compiler performed badly on purpose or if it couldn't do anything even when it was doing its best). Commented Jun 3, 2012 at 21:05
  • 3
    It's an Intel Core i7 processor. Commented Jun 4, 2012 at 18:19
  • Short version: Intel was slower than VS2010. I as well tried this at work not too long ago on a codebase of fairly terse data crunching C++. I tried lots of different settings. Some individual algorithms with already existing performance tests got noticeably faster, but most noticeably slower. Overall any high level operation I did with the software was consistently and measurably slower. I also tried this with the 2013 and 2010 versions of Intel’s compiler, 2010 seems to products better code as well as being more stable. Most of my tests were on a pre-AVX i7, but some were on an older Core2.
    – Rich
    Commented Jan 27, 2014 at 16:26

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.


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.


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.

  • +1. Intel has an ARM compiler ? Unbeleivable!
    – user7071
    Commented Jun 5, 2012 at 11:46
  • 1
    No, intel has no ARM compiler. ARM has an ARM compiler though, which does a fantastic job.
    – martiert
    Commented Jun 5, 2012 at 11:50
  • 2
    "EDIT: arm does not have an arm compiler." is this really what you meant?
    – luiscubal
    Commented Apr 29, 2013 at 21:09

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?

  • The URL link appears to be dead.
    – Contango
    Commented Mar 14, 2017 at 8:26

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.