Branko Badrljica wrote:
BTW: Is ICC really worth the fuss ?
I have checked around and reported that newest gcc-4.3 is able to to
catch and sometimes even outperform icc ( not always, naturally).
Big news seemed to be thatnew gcc si close and sometimes better than icc.
Is it any truth to that and if it is, what is the motive of having
non-open icc option ?
The programs where I care about speed the most are gzip, bzip2, oggenc,
lame, x264... I guess you get the "pattern", they're
encoders/compressors. ICC wins in every one of them (speed increase is
quite dramatic in the case of gzip and bzip2; 20% to 30%). GCC won with
diffutils though; 2% faster than ICC.
Testing other tools is difficult; how do you measure if X is faster with
ICC? Or KDE? (If it even compiles with ICC; didnt' test.)
There's the issue of bugs though; programs break even with different
versions of GCC (see Thunderbird; it breaks when compiled with *any*
form of optimization turned on with GCC 4.3. See bugs 223375 and
217805). Who knows what breakage can occur with ICC. The vast majority
of projects out there are developed and tested only on GCC systems.
Then there's the show stopper #1 bug: every C++ source file that has an
#include <limits.h> refuses to compile with ICC (at least on my system;
AMD64). Intel responds with "use RedHat where it works, we don't
support Gentoo." Supporting ICC in Gentoo is probably going to be too
difficult if Intel refuses to even try to fix bugs that don't show up in
RedHad and Novell's "enterprise" SUSE.
--
gentoo-dev@lists.gentoo.org mailing list
