GCC Optimization

Athena P lists at vega.uk.net
Thu Feb 15 18:02:02 PST 2007



-----Original Message-----
From: lfs-support-bounces at linuxfromscratch.org [mailto:lfs-support-bounces at linuxfromscratch.org] On Behalf Of Ken Moffat
Sent: 16 February 2007 01:07
To: LFS Support List
Subject: Re: GCC Optimization

On Fri, Feb 16, 2007 at 12:15:27AM -0000, Athena P wrote:
> -----Original Message-----
> From: lfs-support-bounces at linuxfromscratch.org
> [mailto:lfs-support-bounces at linuxfromscratch.org] On Behalf Of Ken
> Moffat
> Sent: 10 February 2007 20:22
> To: LFS Support List
> Subject: Re: GCC Optimization
> 
> 
> >(iii) Impact on your processor's caches - a bigger binary increases
> >the pressure on your caches, and may mean more pages have to be read
> >when a program or library is loaded.  For a desktop, it is sometimes
> >asserted that smaller binaries (smaller code, not removing the
> >symbols to give shorter files) will provide a more responsive system.
> 
> 
> Sorry to revisit this post... I just have one more question!
> 
> In a reply to my original post Ken Moffat made the above comment. I have
> also read about this elsewhere. However, does anybody know at what point
> the binary size becomes a problem for my system caches? In particular
> what caches are most affected? 
> 
 The instruction caches, I suppose.  You will note that I said "it
is sometimes asserted" - I've seen LT assert it on lkml, and I used
to believe it myself.  Unless someone is deep into the details of
the cacheing on your particular model of processor, and perhaps the
interaction with CONFIG_HZ in the kernel (the more frequently you
change processes, the worse the pressure on the caches), it's hard
to predict.

> Is it 10% to 15% above the normal un-optimized size? Or is it much more
> or even less?
>

 In principle, any particular data (i.e. instructions) you need is
either already cached, or it isn't.  In practice, different caches
(L1, L2, L3 if you have it) take more time to access.  The bigger
the code, the more quickly it falls out of the caches.
 
> Once again, many thanks! But I suspect this is a "how long is a piece of
> string" type question ;--)
> 
 I agree.  You can run tests on a particular processor and toolchain
to tell you what is best for that combination.  Most of us don't do
that with any sort of rigour.  If you care enough, don't let me
dissuade you from testing optimisations.

ĸen
-- 


Thank You Ken, I appreciate the help

Honestly I am sorry, but I seem to be asking lots of individual questions at the moment. If anybody would be able to humour me with one more, I'd really appreciate it.

I have just finished building gcc-4.1.1 from chapter 6.12 - GCC build.

Keep in mind before answering, I have compiled a highly optimized glibc-2.5 using "-03 -march=prescott -mcpu=prescott -mtune=prescott -mmmx -msse -msse2 -msse3 -m3dnow -fomit-frame-pointer -mfpmath=see" 


My gcc test summary tells me that I have 12 unexpected failures, is this considered normal? Or would you need to see the entire test_summary file?





More information about the lfs-support mailing list