Benchmarking Intel C++ 6.0 to GNU g++ 3.0.4

axehind writes: "Here is a good article detailing a benchmark [comparison] between the two compilers. The results are very interesting."

Re:It shows OOP can take a performance hit

[EvlG]

Abstraction is something that has to be balanced against all forces which impact development, including development time, execution speed, and complexity of the code. Needless to say, these are often divergent factors, and there is often no single answer to them all. Therefore, it is important that the developer have a clear understanding of all constraints on the project and proceed accordingly.

Remember the XP tenet of design something only as complicated as it needs to be to solve the problem. This really isn't anything new; rather, it is just clering up the misconception some people have when they take a good thing too far (see UML, XML, and OOP in general)

Please

[photon317]

Please people, don't go making patches and whatnot for all the standard linux distro package source code to get everyone compiling on this Intel compiler. For normal system services, the performance gain isn't worth the loss of the highly multiplatform and highly GPL gcc we have today, and it would be a shame for gcc to fall by the wayside in common use (probably 80% of gcc compilations are x86 linux) because of small performance gains you won't really notice.

The Intel compiler sounds pretty damn good, but it should really be left for those one-off needs (like compiling a custom scientific application for your beowulf cluster), not general use.

Re:Please

[Permission Denied]

I don't particularly care for one compiler over the other - almost all of my code runs fine under both (I've only recently started playing with icc). The only compiler-dependent thing I've ever used was gcc's inline assembly (which is extremely useful when you need it), but that was only for one project.

I personally like using more than one compiler/libraries just because it makes my code more portable, and it catches dumb mistakes. I usually develop on FreeBSD with gcc, but I'll occasionally I'll compile on a Linux/glibc or Solaris box (using Sun's cc, not gcc), just to make sure I'm not including the wrong header or something.

I have this old Sparcstation 4 running SunOS 4.1. I don't use it for anything vital, but I just like playing with it for nostalgia purposes. Lots of stuff won't compile on it, even using gcc. People sometimes just compile some software for Linux and assume it will work everywhere - I kind of feel sorry for those that have to use HP/UX or AIX, as I know those guys are going to have all kinds of problems.

In short, I agree that the minimal performance gain isn't useful, but portability is important.

Re:Please

[Bert64]

Not just icc, but also SGI cc, Sun cc and Compaq cc, gcc optimizes best for the x86 architecture, and look how much faster icc is in a lot of areas.

All the code i write, is tested on Solaris, IRIX, Tru64, Linux, FreeBSD and NetBSD... using cc whenever possible, performance gains of 600% are possible in some circumstances.. but in almost every case, the vendor cc produces noticeably faster code.

People are complaining about microsoft embracing and extending, yet the gnu folks are doing EXACTLY the same with gcc, glibc and to a lesser extent some other tools.
gcc provides a number of new extensions which aren`t present in any other compiler, and it`s also far more tollerant of code errors than other compilers (remember msie?)
This causes coders to use these nonstandard extensions, and write code which REQUIRES gcc, consequently users are forced to install it and put up with inferior output. Microsoft couldn`t have done it better themselves.
glibc is equally as bad, there have been several security holes, the performance is seriously lacking compared to the old libc5 on older linux distro`s, and theres a high level of incompatibility requiring a lot of code to be rewritten. Then ofcourse we have the embrace and extend features, new features present ONLY in glibc which force users in and try to keep them there.
Why couldn`t these extensions be implemented as a seperate library? for the same reason msie doesnt exist for linux, there would be no way to force users to use your other products.

Now in many ways having a free crossplatform compiler is a good thing, just like microsoft software, but it should be a CHOICE, not something you are forced to use by sloppily written code and propriatory/nonstandard extensions.
Besides, is it not the unix way to have one tool for one job, and do it WELL? how does a compiler for atleast 4 languages, capable of running on 10+ architectures fit with this?

Ask any experienced SUN, DEC or SGI admin, go on irc and join #sgi or #solaris, they will tell you exactly the same as me... gcc is crippling performance ESPECIALLY on non x86 architectures.