-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
