ICC vs GCC vs LLVM/Clang

[dpeterc]

The "conventional wisdom" was that icc was best by large margin (both as code size and speed), gcc most widespread and multiplatform, and Clang immature, but promising. Something along those lines:

http://www.hortont.com/blog/icc-and-mandelbrot/

But I have recently tested those compilers on my project (about 120k lines of C) on OpenSUSE 12.2, and things have changed radically. GCC 4.7.1 is on pair with icc 12.1.5, while Clang is approximately 25% slower. But Clang has excellent compile errors and warnings, and its static analysis is just superb. So some projects are switching from gcc to clang as default compiler.

Has anyone recently (in 2012) done any serious benchmarking of these compilers? Or can you share the benchmark tests of your production code? Which compile options give you best results? What is your justification for using icc, now that free compilers have improved so much?

[dpeterc]

Tim,

I agree gcc also changes the options from release to release, it is normal evolution. But in my opinion icc is more drastic in that respect.

Sergey, thansk for the list, really helpful for someone who uses several compilers. Maybe for Mingw, mention actual version of gcc compiler. If you have time, please add clang.

[SergeyKostrov]

>>...Maybe for Mingw, mention actual version of gcc compiler... It is 3.4.2 and upgrade to a newer version is scheduled. Please also verify how options /Wport and /Qeffc++ work. ... /Wport issue portability diagnostics /Qeffc++ enable effective C++ diagnostic warnings ...

[SergeyKostrov]

>>...Please also verify how options /Wport and /Qeffc++ work... Only 8 issues are detected when I used /Qeffc++ Intel C++ compiler option. Here is a consolidated list of warnings: Warning 2012 - Effective C++ Item 1 prefer const and inline to #define Warning 2013 - Effective C++ Item 2 prefer iostream to stdio Warning 2014 - Effective C++ Item 3 prefer new and delete to malloc and free Warning 2015 - Effective C++ Item 4 prefer C++ style comments Warning 2017 - Effective C++ Item 6 missing delete of member pointer member "..." in destructor Warning 2021 - Effective C++ Item 11 declare a copy constructor and assignment operator for "..." Warning 2022 - Effective C++ Item 12 field member "..." not initialized (preferable to assignment in constructors) Warning 2027 - Effective C++ Item 15 make sure operator = returns a *this

[nedo_n_]

Hi,

I have just bought the latest Intel compiler 14 and one of xeon phi devices http://ark.intel.com/it/products/71992/Intel-Xeon-Phi-Coprocessor-5110P-8GB-1_053-GHz-60-core

I would like to know what are the best optimization options since I tried to compile my code and latest gcc 4.8.2 is still faster than intel 14.

I read this guide about building a code for xeon phi http://software.intel.com/en-us/articles/building-a-native-application-for-intel-xeon-phi-coprocessors. So it seems that with a flag -mmic I can run natively my code on xeon phi. Are there some tips to take into account?

Thank you

[TimP]

Are we to assume that your code which works well with gcc is suitable also for Intel(r) Xeon Phi(tm)?  Then presumably it is vectorizable without difficulty and thread parallel, and the optimization reports should be meaningful, so you can check whether you have specified unrolling effectively (e.g. -unroll2 for Haswell, if that is what you use for gcc).

If you use -fcx-limited-range (implied by gcc -ffast-math) you should use icc -complex-limited-range.

It is possible for automatic memcpy substitutions to be slower than gcc code.  Such substitutions should be reported in opt-report.

If gcc is giving full performance, it may be tough for icc to come out ahead.

Under -mmic, if you use -fp-model source to gain accuracy, you must try to set -ftz -no-prec-div -no-prec-sqrt to retain some performance.  KMP_PLACE_THREADS environment variable is important, along with OMP_PROC_BIND or equivalent settings.  I assume you're not talking about MIC when you say gcc performs well.