Gentoo Archives: gentoo-performance

From: Colin Kingsley <ckingsley@×××××.com>
To: gentoo-performance@l.g.o
Subject: Re: [gentoo-performance] inline considered harmful
Date: Thu, 22 Jul 2004 05:47:11
Message-Id: 13cc2f7804072122474623f217@mail.gmail.com
In Reply to: Re: [gentoo-performance] inline considered harmful by Colin Kingsley
Does this also apply to ppc architecture? There must be more to
consider for ppc, ie. more registers than x86, etc.

On Thu, 22 Jul 2004 01:44:36 -0400, Colin Kingsley <ckingsley@×××××.com> wrote:
> true, you could, but it would be much neater to use -O3 and disable > stuff using -fno-whatever. Also, this would have the benefit of > remaining usefull even if a new version of gcc had a diferent set of > optimisations in -O3. > > but thats just my oppinion:) > > > > > On Wed, 21 Jul 2004 21:16:43 -0400, Douglas Breault Jr. > <genkreton@×××××××.net> wrote: > > You could just enable -O2 and the following: -frename-registers and -fweb. -O3 is simply -O2 plus those 3 options. > > > > > > > > On Wed, 21 Jul 2004 20:50:01 -0400 > > Adam Petaccia <adam@×××××××××.com> wrote: > > > > > With gcc, is there a way to enable all -O3 options but function > > > inlines? Would -fno-inline work or something like that? > > > > > > Mario Domenech Goulart wrote: > > > > > > >Hello, > > > > > > > >There's an interesting discussion in the OpenBSD mailing > > > >list about the use of inline. > > > > > > > >Here's the beginning of the thread about this topic: > > > > > > > >,----[ http://www.sigmasoft.com/cgi-bin/wilma_hiliter/openbsd-tech/200407/msg00175.html ] > > > >| inline considered harmful. > > > >| > > > >| * To: tech@×××××××.org > > > >| * Subject: inline considered harmful. > > > >| * From: Artur Grabowski <art@××××××××.org> > > > >| * Date: 21 Jul 2004 03:54:46 +0200 > > > >| * User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 > > > >| > > > >| Today we did a bunch of removal of inline functions in the kernel. > > > >| It all started to make floppies fit, but now it's a quest. > > > >| > > > >| If you think that I'm crazy doing this because it might hurt your > > > >| precious performance, go back to your vax and leave the performance > > > >| tuning to people who have a cache. > > > >| > > > >| Every single inline we removed today (and there are more in the > > > >| pipeline and even more waiting to be fixed) shrunk the code and MADE > > > >| IT FASTER. Yes, modern cpus have something called "cache". The cache > > > >| prefers the code to be smaller, rather than free from function calls. > > > >| Yes, some cpus have expensive function call overhead. Don't use them. > > > >| i386 has quite expensive function calls, on the other hand it doesn't > > > >| have any relevant amount of registers either. So a function call > > > >| instead of the same function inlined can potentially make the job > > > >| easier for the register allocator in the compiler which could eat the > > > >| overhead. At the same time the instruction cache can run the same code > > > >| in the same place, instead of loading it from main memory 4711 times. > > > >| And guess what? The stack on i386 is in the cache too, so the function > > > >| call overhead isn't that bad anyway. > > > >| > > > >| I'm tired of seeing code where everything is made inline just because > > > >| someone acted on a meme that hasn't been true for over a decade. Bloat, > > > >| bloat and more bloat. Since people can't use inline correctly (it does > > > >| have valid and correct uses), from now on inline in the OpenBSD kernel > > > >| is considered to be a bug until proven otherwise. So. Next time I see > > > >| code that adds to the bloat with inlines, I expect performance figures > > > >| and kernel size comparisons that show that the inline actually > > > >| contributes anything. Otherwise the code does not go in. > > > >| > > > >| There's still a lot of work to be done in the kernel (yes, macros can > > > >| be evil too, just see nfs), so send diffs. And there's a whole > > > >| unexplored field in userland too. > > > >| > > > >| //art > > > >`---- > > > > > > > >Mario > > > > > > > > > > > >-- > > > >gentoo-performance@g.o mailing list > > > > > > > > > > > > > > > > > > > > > > -- > > > gentoo-performance@g.o mailing list > > > > > > > > > >
-- gentoo-performance@g.o mailing list