Gentoo Archives: gentoo-performance

From: Jerry McBride <mcbrides9@×××××××.net>
To: gentoo-performance@l.g.o
Subject: Re: [gentoo-performance] inline considered harmful
Date: Thu, 22 Jul 2004 15:05:50
In Reply to: Re: [gentoo-performance] inline considered harmful by Bart Alewijnse
On Thursday 22 July 2004 02:35 pm, Bart Alewijnse wrote:
> I'm curious as to how many of you have considered and tried using -Os > for your programs, and it might even apply to parts of the kernel. > > I'm not kidding. On half of my C++ programs, usually those that deal > with mostly hard processing, there is no discernable difference > between -O2 or -O3 and -Os, except that -Os executables are smaller, > and every now and then a benchmark (though that tends to be 'do > something a lot of times in a row', which of course is mostly a > nonsense benchmark) will turn out faster - I have yet to see a case in > which -Os performs noticeablyworse - and most of the time it's about > the same, although that might just be the sort of things I use C for. > > That code size in itself seems to almost completely balance the > optimisations gcc can do (...not that -Os has no optimisations at > all), especially for what in practice are my small, central object > files gave me a whole new perspective on how much more central the > cache is to speed these days. I think many more programs could > benefit, actually. > > For the heck of it, I just compiled md5 with it standard O3 and with > Os. It made a tiny yet > of 150 to 200 ms in favour of Os. (on a a scale of 26 seconds; I used > kcore, so caching should have had no effect [actually, on a 100MB file > in shm, well within cacheability, O3 was faster, by abotu the same > amont, on a 3 second scale (I did this on a slower processor, > 'course)]) But md5 isn't the best example, as it's data crunching, and > not very complex code. I'ld be amazed if it weren't completely cached > either way - the seven hundred bytes or so in executable size > difference (scale of 13K) saved there aren't the most important ever - > except that can be taken to be purely in code, which is partly the > point. > > So I'm even more interested now. It would amuse me if you would humour > me for a few minutes and compile and run a few of your own C programs > (that don't bottleneck on syscalls or io) with Os, see whether it > makes a difference, and in what direction and magnitude. > > Just for kicks, I just compiled my kernel (2.6.7 ck) with Os. It's a > shame it'd hard to measure the speed difference, but it does knock > 300K (~12%) off its size. I think I'll run it for a while, see what > happens. >
I've been there, done that and bought the t-shirt... Well... maybe I just looked at the t-shirt.... Anyway, I tried Os, O2 and O3 on a number of different packages on a gentoo box running on an AMD XP2500 clocked to 2.5ghz. My test results were at best ambigeous and didn't reflect what the main stream purporters of "BIG PERFORMANCE GAINS" with magical compiler settings. At first I thought I was onto something, but then, like yourself figured out that it was mostly "smoke and mirrors". Compiler options are best used to optimized specific applications. Over all use, across an entire linux installation... no one option is better than the other. That's been my observation, shoot me if you wish. :') I just run CHOST="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe" CXXFLAGS="${CFLAGS}" in /etc/make.conf and forget about the optimization madness... Besides, most of the ebuilds specify their own optimization settings anyways... Cheers. -- ****************************************************************************** Registered Linux User Number 185956 FSF Associate Member number 2340 since 05/20/2004 Join me in chat at #linux-users on Buy an Xbox for $149.00, run linux on it and Microsoft loses $150.00! 10:49am up 93 days, 13:31, 7 users, load average: 0.02, 0.07, 0.08 -- gentoo-performance@g.o mailing list


Subject Author
Re: [gentoo-performance] inline considered harmful Bart Alewijnse <scarfboy@×××××.com>
Re: [gentoo-performance] inline considered harmful William Kenworthy <billk@×××××××××.au>