At 05:21 PM 8/1/00 -0400, John Tobey wrote:
>Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> > John Tobey <[EMAIL PROTECTED]> writes:
> > >Is foo() compiled any differently in
> > >
> > > inline i_foo() { BLA; BLA; BLA; }
> > > foo() { i_foo(); }
> > >
> > >versus
> > >
> > > foo() { BLA; BLA; BLA; }
> >
> > Maybe not for void functions with no args, tail-called and with
> > no prefix, but in more typically cases yes it can be different
> > the "function-ness" of i_foo applies constaints on where args
> > and "result" are which optimizer _may_ not be able to unravel.
>
>May not be able because of what the Standard says, or because of
>suboptimal optimization?
Both, with a smattering of uncertainty about pointers thrown in for fun, I
expect.
> > >? I am not talking about forcing inlined functions down anyone's
> > >throat.
> >
> > I believe that if function is defined before use "modern" C compilers
> > (e.g. gcc) can inline functions not declared such.
>
>GCC won't unless you go -O3 or above. This is why many people (me
>included) stop at -O2 for most programs.
That's not necessarily a wise choice in all cases, though the compiler may
be making stupid choices as well. If a function's used only once inlining
makes sense, but if it isn't it might not, depending on how the optimizer
can savage the thing.
> > >Non-inline functions have their place in reducing code size
> > >and easing debugging. I just want an i_foo for every foo that callers
> > >will have the option of using.
> >
> > Before we make any promises to do all that extra work can we
> > measure (for various architectures) the cost of a real call vs inline.
> >
> > I want proof that inline makes X% difference.
>
>I'm not going to prove that. A normal C function call involves
>several instructions and a jump most likely across page boundaries.
But if that function is already in cache from another use, you win.
Assume, for a minute, you've got a 700MHz system with a 100MHz 128-bit data
bus. If your code is inlined and works out to 256 bytes, that's 16 fetches
on the main bus. That costs 112 cycles. On the other hand, if your
function's *not* inlined, you pay the cost for function setup and call.
(Which is pretty cheap, certainly far less than 112 cycles) Is inlining a
win in this case? Probably not, as you'll be spending a good deal of time
(even with the CPU pipeline-from-hell, which can actually exacerbate cache
miss costs) waiting on the main memory system.
>If someone else wants to prove this, great. I just don't think it's
>that much trouble. (mostly psychological - what will people think if
>they see that all our code is in headers and all our C files are
>autogenerated?)
They'll realize that all those .PI files have the real code in it? :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
