From: Adrian Bunk <bunk@stusta.de>
To: "J.A. Magallón" <jamagallon@ono.com>
Cc: "Linux-Kernel, " <linux-kernel@vger.kernel.org>
Subject: Re: Inlining can be _very_bad...
Date: Fri, 30 Mar 2007 00:28:32 +0200 [thread overview]
Message-ID: <20070329222832.GE14134@stusta.de> (raw)
In-Reply-To: <20070330000111.620aaaab@werewolf-wl>
On Fri, Mar 30, 2007 at 12:01:11AM +0200, J.A. Magallón wrote:
> On Thu, 29 Mar 2007 19:52:54 +0200, Adrian Bunk <bunk@stusta.de> wrote:
>
> > On Thu, Mar 29, 2007 at 01:18:38AM +0200, J.A. Magallón wrote:
> > > Hi all...
> > >
> > > I post this here as it can be of direct interest for kernel development
> > > (as I recall many discussions about inlining yes or no...).
> > >
> > > Testing other problems, I finally got this this issue: the same short
> > > and stupid loop lasted from 3 to 5 times more if it was in main() than
> > > if it was in an out-of-line function. The same (bad thing) happens if
> > > the function is inlined.
> > >...
> > > It looks like is updating the stack on each iteration...This is -march=opteron
> > > code, the -march=pentium4 is similar. Same behaviour with gcc3 and gcc4.
> > >
> > > tst.c and Makefile attached.
> > >
> > > Nice, isn't it ? Please, probe where is my fault...
> >
> > The only fault is to post this issue here instead of the gcc Bugzilla.
>
> Sorry, my intention was just something like 'take a look at your
> reduction-like code, perhaps its sloooow', something like checksum
> funtions in tcp or raid that are inlined expecting to be faster
> and in fact they are slower...
Unless a function that has more than 1 caller is very tiny or reduces at
compile time to a very tiny rest, it's not expected that inlining was
faster on current CPUs.
But most times that's already only up to the compiler - e.g. current gcc
versions already automatically inline all static functions with only
1 caller.
> > In your example the compiler should produce code not slower than with
> > the out-of-line version when inlining. If it doesn't the bug in the
> > compiler resulting in this should be fixed.
>
> That's what I expected, but...
> Going to gcc bugzilla...
Thanks.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
prev parent reply other threads:[~2007-03-29 22:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-28 23:18 Inlining can be _very_bad J.A. Magallón
2007-03-29 1:29 ` Benjamin LaHaise
2007-03-29 17:52 ` Adrian Bunk
2007-03-29 22:01 ` J.A. Magallón
2007-03-29 22:28 ` Adrian Bunk [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070329222832.GE14134@stusta.de \
--to=bunk@stusta.de \
--cc=jamagallon@ono.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.