The good way to use it under Linux

The good way to use it under Linux

Ritratto di shrom

Hi, I'm not professional C developper and I wonder how to use
ICL7 under Linux.

I've tried:
-export CC=icc
-export CFLAGS="-O3 -rcd -xM -ip"
-configure
-make
but the resulting exe is not very fast.
I've made test with lame (mp3 encoder) build, the resulting exe is faster when it is build with gcc2.95 than with icl7.

4 post / 0 new
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione
Ritratto di Tim Prince

I must say that the advantages of icc don't begin to kick in until you use at least PentiumPro switches, and the additional optimizations in 7.0 appear to pertain mainly to the -xW/-axW options. So, if your machine is really over 5 years old, I wouldn't be surprised at weak results.
Even experts get tripped up over one of the differences in default optimizations:
gcc -O implies -fstrict-aliasing (since gcc-2.95.3);
in order to match this, use
icc -ansi_aliasing
My 'info icc' says that the default is supposed to be consistent with gcc, but you should check that. The default has been to be consistent with Microsoft, and ICL would default that way.

I don't know about lame, but some of these encoders use backward loops, which icc doesn't always optimize.
There may be dependencies on use of the PGO process (prof_gen/prof_use) in order for icc to match gcc performance. gcc has such an option as well, but it's not so important.
I've seen a case where it appears that gcc does a more thorough job of setting arrays on appropriate alignments (unless you instruct it not to do so, e.g. by -Os), without requiring the use of sse-specific alignment directives.
I would like to see more people submitting problem reports to premier.intel.com, when they can show specific performance issues, like the data alignments and not optimizing the backward loops.
Many people simply go ahead and do low level coding when they want performance on applications such as this, without looking at what the compiler should be capable of doing at a higher level.

Ritratto di Anna N.

> Many people simply go ahead and do low level coding
> when they want performance on applications such as
> this, without looking at what the compiler should be
> capable of doing at a higher level.

Just my two cents - higher level optimizations are incredible if talking about algorithm choice. However, compiler optimizations can be very inconsistent as one build can be 20% faster than the next, while, from the programmer's point of view, code is still the same.

Also, some of compiler optimizations may be - and often are - dependent on #pragma's, or restrict, align and other keywords, that have to be inserted into the code; this makes "just recompile" not that useful. Piece of unfamiliar code that requires many inserts of keywords may turn out either too complex to bother changing or easier to rewrite in low-level.

Regards, Anna

Ritratto di scottrobertladd

Rather than try and replace gcc with icc, I've created separate makefiles for each compiler. While both compilers have very similar options, there's enough subtle differences that I prefer to tune compilation for the compiler at hand.

Also note that no matter how good your compiler is, better algorithms produce the greatest performance gains. Profile code to find and correct bottlenecks. Optimization is a wonderful thing, but there are limits to how much gain you'll get from even the best compiler.

Accedere per lasciare un commento.