Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
I would guess they do it because they need some specific feature of that compiler that others do not have. Or maybe they want paid support from Intel if things go wrong? I don't know for sure, having never done it myself... –  FrustratedWithFormsDesigner Aug 4 '11 at 15:45
15  
Intel Compilers have a reputation for producting very efficient numerical code. –  quant_dev Aug 4 '11 at 15:51
2  
@honk: If quant_dev can provide some links to back that up, then yes it should be! –  FrustratedWithFormsDesigner Aug 4 '11 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. –  Mason Wheeler Jun 4 '12 at 22:43
2  
@RocketSurgeon open source has nothing to do with money. –  kaoD Jun 5 '12 at 1:13
show 9 more comments

9 Answers

up vote 38 down vote accepted

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.

share|improve this answer
1  
There is no -O3 flag for Microsoft's C++ compiler. There's -O1, -O2, and -Ox. You must be thinking of GCC. :-) –  Cody Gray Jun 3 '12 at 13:04
    
Yep, I've used GCC more. I'll fix the answer. –  K.Steff Jun 3 '12 at 14:03
11  
There have been some heavy accusations about artificially induced inferior performance on CPUs by other vendors. As your link shows, it's not just accusations -- they do intentionally disable a significant number of optimizations on non-Intel processors. This went to court and they lost (although the ruling only says they have to admit that they do it now). –  Brendan Long Jun 3 '12 at 21:02
1  
@BrendanLong True, but then again, they have been accused of much more than that: if you read the first quote, there's an accusation that if the CPU is not GenuineIntel, the program doesn't run at all, while this one (as of now) is not true. Also, they have settled, not lost. Still, they're not the white-hat guys in any case... –  K.Steff Jun 4 '12 at 21:18
    
@BrendanLong Also, great comment, and I've edited my answer accordingly :) –  K.Steff Jun 6 '12 at 20:34
show 2 more comments

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

http://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.

share|improve this answer
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 Aug 4 '11 at 17:53
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
Would you mind sharing the details of the CPU the benchmarks ran on? –  Oak Jun 3 '12 at 13:05
17  
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. –  Cody Gray Jun 3 '12 at 13:06
1  
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). –  Brendan Long Jun 3 '12 at 21:05
2  
It's an Intel Core i7 processor. –  Mason Wheeler Jun 4 '12 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 Jan 27 at 16:26
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
Did you mean Visual Studio? –  Michael Dorst Aug 18 '13 at 23:26
    
@MichaelDorst Thanks. Fixed. –  David Schwartz Aug 18 '13 at 23:31
add comment

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.

share|improve this answer
    
+1. Intel has an ARM compiler ? Unbeleivable! –  user7071 Jun 5 '12 at 11:46
1  
No, intel has no ARM compiler. ARM has an ARM compiler though, which does a fantastic job. –  martiert Jun 5 '12 at 11:50
2  
"EDIT: arm does not have an arm compiler." is this really what you meant? –  luiscubal Apr 29 '13 at 21:09
add comment

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?

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.