GCC Optimization

Ken Moffat ken at linuxfromscratch.org
Thu Feb 15 17:06:37 PST 2007


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
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the lfs-support mailing list