Intel C++ compiler value proposition

[Ganesh_R_Intel]

My first message on this forum. :-)

I will start out with a question I always wanted to ask, but did not know the right forum.

Here goes.

Our marketing folks pitch our C++ compiler's value as follows:

1. Performance - Intel C++ Compiler builds the FASTEST code for the latest processor

2. Compatibility - Intel compiler is compatible with the leading vendor (Microsoft .NET/ Visual C++ 6.0 on windows and GNU gcc on linux). It makes your life easy when you go back and forth and get that one hotspot optimized by next Tuesday.

3. and Support

Please set me straight. Do you agree? Disagree? Dont care?

Regards,
Ganesh

[richard-j-smith7]

Our primary reason for using the intel c++ compiler is better standards conformance. The MS VC++ 6 and VS.Net C++ compilers can not handle some of the templated code we have. If we can get better performance, thats just a bonus.

[Ganesh_R_Intel]

Richard,
Noted.Your insight is valuable.

Thanks,
Ganesh

[njd]

From some initial experiments, your standards compliance is
definitely a strong point; more so than compatability with gcc or MS compilers.

Performance is also a strong consideration, especially vectorization. I am interested in, but have not yet explored, your automatic parallelization. I'm interested in exploiting it on hyper-threaded Xeons. I'm quite curious about the speedup on hyperthreaded processors as opposed to a physically disjoint multiprocessor, and the behaviour on a multiprocessor, hyperthreaded machine. For example, does the compiler take cache sharing into account for logical processors? It seems easy to blow the caches when using 2 logical processors on the same chip, though using a thread for prefetching seems effective..

[erichvdschatzinsel]

Hi,

> 1. Performance - Intel C++ Compiler builds the
> FASTEST code for the latest processor

This is the main reason why we are considering it at the moment. We are developing server applications where performant software saves money on the hardware. Even if it is just buying the new hardware a bit later.
>
> 2. Compatibility - Intel compiler is compatible with
> the leading vendor (Microsoft .NET/ Visual C++ 6.0 on

This makes is easier to move.
>
> 3. and Support

This is not a reason to choose a compiler. A compiler must be this reliable that it does not need support. The work of your developers is much more important to me than the support given later.

Erich

[pike]

There are also a few freeware compilers. ;)
Try Digital Mars's compiler. Completely free, & it does the job great.
It has a decent speed. It's the one I use. Read the readme.txt or readme.html. It tells you how to run it. It is very simple, really.

By the way, I have nothing to do with Digital Mars, but I think their compiler is pretty decent.

Thanks, Pike

[Anna_N_]

First of all: ICC is great; the following are rare problems.
Second: My comments are about 5.x/6.x eval versions.

> 1. Performance - Intel C++ Compiler builds the
> FASTEST code for the latest processor

Unoptimized FP/int code - definitely yes.
Optimized fp/int - usually yes.
Optimized int, memory intensive - well, not, MSVC better (why? don't know).

Guesstimating 99.9% of software in first two categories, and 99% in the first. That fixes the problem of the third.

I'd still like to see improved register assignment in 5-8
vars tight loops with MMX/SSE/SSE2 intrinsics.

> 2. Compatibility - Intel compiler is compatible with
> the leading vendor (Microsoft .NET/ Visual C++ 6.0 on
> windows and GNU gcc on linux). It makes your life
> easy when you go back and forth and get that one
> hotspot optimized by next Tuesday.

MSVC - yes. ICC sometimes better, compiling code VC can't touch. Drop-in replacement is great.

GNU - don't know; heard of kernel not compiling on ICC; is it still true?
Speedwise ICC is the best however.
Not that I care about linux with all the library incompatibilities. An optimizing linker, anyone? I, for one, don't like to distribute statically linked 1.4MB of my 'Hello world!' app.

> 3. and Support

On linux, free versions don't have support. Besides, that's a compiler. You read manual (30m), write down useful switches (15m), check syntax of intrinsics (15m), then write, compile, write, compile... And app runs fast.
Support is "Well, this bug's actually a feature; next version will have it fixed; it's only 6 months away". Am I wrong?

> Please set me straight. Do you agree? Disagree? Dont
> care?
>
> Regards,
> Ganesh

My bottom line about ICC: the greatest! It still could be better, though.

Regards,

Anna

[duvanenko]

I've been using the Intel C++ Compiler for the last 2.5 years and have given lots of feedback. To me and my company the following priorities are most important:

1. Speed is everything. More speed is better. Speed is everything, once again ;-)
2. C++ compliance is nice, but not a requirement, and once again speed is more important.
3. Support is very important! We don't expect minor bugs to be fixed immediately (look at other compilers), but fixed in the future minor or major releases. We're a software developer ourselves and understand the complexities. Ability to feedback suggestions for speed improvements is crucial - we have a long-term view, we want more speed in the future. Have I mentioned that speed is everything ;-) and is the overwhelming reason that we use the compiler (if we didn't care about speed, we'd use someone else's compiler).
4. Long-term survival is also very important. If we are going to use a tool, and comit time and resources to learning it and crafting our code to work well with it, then it is very important that this tool survives for a long time (especially if it is valuable).

Keep on adding value, and being able to extract more performance out of Intel processors with less effort is your highest added value.
-Victor

[deepak1]

I like ICL because it is more standards compliant than
VC, and generally faster than gcc,metrowerks on windows, has things we like partial template specialization (on that note does version 7.0 fix the specialization problem for pointers?), etc.

However the various knobs like vectorization, Qipo, G7
(I use a P4), in my experience has never bought us anything over a standard -O2 kind of optimization, In fact the vectorization option slows us down by about 5%!
I've seem some speedup switching to using the sse2 intrinsics, but here too I've seen strange behaviour, I've seen slowdowns depending on the vector sizes we work
with(btw power of two).

Also a pesky compiler bug we see is Internal compiler error bug which seems to happen in debug builds when you a static variable defined inside a function - doesnt happen always, so cant say for sure? Are you aware of this/or a similar problem,
Thanks,
Deepak

[TimP]

Vectorization often favors loop lengths which are a multiple of 8, so it is likely to be slower for shorter loops. It is most effective when the arrays start on 16-byte boundaries.

[Ganesh_R_Intel]

Anna,
Thanks for the posts! I hope you find these forums useful and interesting.

>Support is "Well, this bug's actually a feature;
>next version will have it fixed; it's only 6 months
>away".
>Am I wrong?
I certainly hope so!

Regards,
Ganesh

[Ganesh_R_Intel]

Duvanenko,
Thanks for the comments!

>extract more performance out of Intel processors
>with less effort is your highest added value
This is completely in sync with the compiler design goals. And let the compiler do the work for you...

Cheers,
Ganesh

[Ganesh_R_Intel]

>Also a pesky compiler bug we see is Internal
>compiler error bug which seems to happen in debug builds

Deepak - It would be great if you can capture this.

A good next step to isolate most issues seen at compilation (irrespective of the compiler) and submit it to the vendor is -
(i) Create a .i file . This would be the proprocessor output with all the header files munged in. The -P option.
(ii) Make sure that you see the problem with the .i file (You may have to rename it to .cpp or .c or explicitly tell the compiler that the .i file is a C/C++ file)
At this point you have a standalone testcase, albeit a long one.
(iii) Optional - Intel compilers come bundled with a tool called icpi to cutdown standalone compilation issues. Please see docs.This can help reduce the testcase in an automated way.
(iv) Optional - You could also obfuscate your code if you are concerned with IP issues.

Thanks for a great post!

Ganesh

[ksirotinskiy]

Victor,

This is your cousin, Kirill. I'm trying to find you, but your numbers and emailsare changed. Please, call (646)248-0-842 or +7(921)910-3543. Otherwise, write me at kir@kirasir.com.

Kirill