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