[gentoo-dev] Re: ICC Profile

[gentoo-dev] Re: ICC Profile

[Nikos Chantziaras]

Adam Stylinski wrote:
> The intel C Compiler (icc) has an ebuild for gentoo and the wiki has
> a script to integrate it with portage.

I'm using ICC for programs where I have numbers about performance; for 
example, bzip2 is 30% faster here when compiled with ICC.

However, one thing I don't like about ICC is that when you post in the 
Intel forums about a problem you have on Gentoo, the reply is "Gentoo is 
not supported, please use RedHat."  If Gentoo is going to "support" ICC, 
ICC should be supporting Gentoo as well.

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: ICC Profile

[Adam Stylinski]

I actually know somebody working at intel, maybe he can get them more involved.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: ICC Profile

[Branko Badrljica]

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 ?





Adam Stylinski wrote:
> I actually know somebody working at intel, maybe he can get them more involved.
>   

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: ICC Profile

[Adam Stylinski]

GCC 4.3 is catching up, but they are no where near utilizing SSE4 or SSE5 instructions.  

http://blog.alphagemini.org/2008/03/icc-vs-gcc-43.html

He concludes that it's not worth pursuing, but I beg to differ.  Those are signifcant differences for a processor.
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: ICC Profile

[Nikos Chantziaras]

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

Re: [gentoo-dev] Re: ICC Profile

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

On Fri, 18 Jul 2008 10:24:58 -0400 (EDT)
Adam Stylinski <stylinae@email.uc.edu> wrote:
> GCC 4.3 is catching up, but they are no where near utilizing SSE4 or
> SSE5 instructions.  
> 
> http://blog.alphagemini.org/2008/03/icc-vs-gcc-43.html
> 
> He concludes that it's not worth pursuing, but I beg to differ.
> Those are signifcant differences for a processor.

He doesn't establish whether the code in question is highly cpu-bound
or not when run on his system. For a lot of memory- and i/o-bound code,
there's little practical difference between gcc with optimisations
turned off and gcc with -frice-my-shorts except that the former
compiles an order of magnitude faster.

The more interesting question, then, is whether users run any
non-trivial cpu-bound programs. We know the applied science types do,
but they tend to be the ones who're doing clever things with icc
anyway. What about normal users?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: ICC Profile

[Adam Stylinski]

He's also doing it on a core 2 duo.  It would be interesting to compare this with some mildly legacy hardware (netburst pipelines) in order to see whether GCC does a comparable job.  My guess would be no, seeing as netburst was extremely ugly and complicated, only intel would be able to write a compiler that took advantage of it.  
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: ICC Profile

[Richard Freeman]

Ciaran McCreesh wrote:
> 
> The more interesting question, then, is whether users run any
> non-trivial cpu-bound programs. We know the applied science types do,
> but they tend to be the ones who're doing clever things with icc
> anyway. What about normal users?
> 

I'm sure they do on some occasion if they encode compressed audio/video, 
or when compressing data with zip/etc.  That is probably the biggest 
application of cpu-bound software.

Personally, I use -Os across the board when it doesn't break.  As you 
said I tend to be memory/IO bound, and optimizing for size helps with 
both (swapping causes IO).  I'd probably benefit from using -O3 on the 
aforementioned CPU-intensive apps.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: ICC Profile

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

On Fri, 18 Jul 2008 15:34:53 -0400
Richard Freeman <rich0@gentoo.org> wrote:
> Ciaran McCreesh wrote:
> > The more interesting question, then, is whether users run any
> > non-trivial cpu-bound programs. We know the applied science types
> > do, but they tend to be the ones who're doing clever things with icc
> > anyway. What about normal users?
> 
> I'm sure they do on some occasion if they encode compressed
> audio/video, or when compressing data with zip/etc.  That is probably
> the biggest application of cpu-bound software.

How much of that is memory bound? Of the things that aren't, how many
aren't written in assembly anyway? Of those things, what proportion of
the runtime is spent in those areas?

If you double the speed of something that takes up 2% of the overall
execution time, you can't measure the improvement.

Or looking at it the other way -- is there any reason to believe that
using icc (which can end up being a substantial pain in the arse, given
the way it tries to use gcc's c++ headers but doesn't support some of
the extensions or quirks that g++ does) will provide a genuine gain
for people who aren't already doing clever profile-directed trickery
anyway?

> I'd probably benefit from using -O3 on the aforementioned
> CPU-intensive apps.

The problem with -O3 is that function inlining can lead to a
substantial cache hit. Unless you're using profile-directed
optimisations, which Gentoo doesn't support, it's extremely hit and
miss as to whether O3 helps or hurts.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] Re: ICC Profile

[Richard Freeman]

Ciaran McCreesh wrote:
> 
> How much of that is memory bound? Of the things that aren't, how many
> aren't written in assembly anyway? Of those things, what proportion of
> the runtime is spent in those areas?
> 
> If you double the speed of something that takes up 2% of the overall
> execution time, you can't measure the improvement.
> 
> Or looking at it the other way -- is there any reason to believe that
> using icc (which can end up being a substantial pain in the arse, given
> the way it tries to use gcc's c++ headers but doesn't support some of
> the extensions or quirks that g++ does) will provide a genuine gain
> for people who aren't already doing clever profile-directed trickery
> anyway?
> 
> 
> The problem with -O3 is that function inlining can lead to a
> substantial cache hit. Unless you're using profile-directed
> optimisations, which Gentoo doesn't support, it's extremely hit and
> miss as to whether O3 helps or hurts.
> 

I agree with all of the above.   Gentoo is about choice, so if people 
want to make ICC work well more power to them.  I agree that it would be 
hard to make it THE ONLY system compiler.  For those who do try it I'd 
be really interested in their findings.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: ICC Profile

[Adam Stylinski]

Perhaps we could write a script that compiles packages in portage with both ICC and GCC and runs them with different flags.  I think there was an effort on the GCC side already to test flags with specific packages.  We can then have the script run time on the applications doing work (again, that's a lot of packages for a lot of different tasks).  If we can store these in the portage tree (yes, it's more metadata), the user can actually benefit well from the optimizations.
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: ICC Profile

[Duncan]

Richard Freeman <rich0@gentoo.org> posted 4880F05D.4010905@gentoo.org,
excerpted below, on  Fri, 18 Jul 2008 15:34:53 -0400:

> Personally, I use -Os across the board when it doesn't break.  As you
> said I tend to be memory/IO bound, and optimizing for size helps with
> both (swapping causes IO).  I'd probably benefit from using -O3 on the
> aforementioned CPU-intensive apps.

I did before gcc-4.3, but with 4.3, several of the other flags (-freorder-
blocks-and-partition, for instance, which increases cache hit rates but 
also increases size) I was using folded into -O2 but not -Os, and I 
decided -O2 was a better choice as a result.

Has anyone done a study of -Os vs -O2 with gcc-4.3.x, similar to the ICC/
gcc-4.x study linked upthread?  On x86_64 would be an extra bonus, 
particularly if it were on AMD, or if both Intel and AMD were studied, as 
would the effect of such flags as -freorder-blocks-and-partition, as 
mentioned above.  I'd love to see links, if so!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: ICC Profile

[Rémi Cardona]

Duncan wrote:
> Has anyone done a study of -Os vs -O2 with gcc-4.3.x,

Just a quick note while on the subject : -Os is known to break some 
packages.

Although it has been a while since I've last had a full -Os system, 
there was a time when -Os was a _very_bad_idea_. That's why the Gnome 
Herd (and upstream Gnome) won't support anything more than -O2.

Of course, if anyone wants to use -Os to actually fix bugs... :)

Cheers

Rémi
-- 
gentoo-dev@lists.gentoo.org mailing list