At 04:55 PM 8/1/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 04:37 PM 8/1/00 -0400, John Tobey wrote:
> > >Is foo() compiled any differently in
> > >
> > > inline i_foo() { BLA; BLA; BLA; }
> > > foo() { i_foo(); }
> > >
> > >versus
> > >
> > > foo() { BLA; BLA; BLA; }
> > >
> > >?
> >
> > Probably. On many newer chips, the first form will probably get you a
> > function called i_foo and foo will call it, rather than actually inlining
> > the code. (Depends on how often i_foo is called) Function calls are
> > reasonably cheap, and if you have one copy of the function instead of
> many,
> > it may well be in the cache already, where it wouldn't be in the
> inlined case.
> >
> > Given that some of the faster machines take a 10x speed hit getting to
> main
> > memory, that can make a *big* difference.
>
>Well, I am going to assume you are wrong and the above two foo()
>implementations will produce exactly the same code.
Your assumption is incorrect for good compilers. (Whether gcc counts as
good for a particular platform is a place I'm Not Going right now) Compaq C
will do it differently depending on the number of times that the inlined
function is used. (The more data it has the better the guess it makes,
which is one reason I want to be able to glob all of the core perl source
into one file for ultimate compilation)
>I think GCC lets
>you control whether i_foo becomes a bona fide symbol by letting you
>declare it `extern inline'. In any case, I do *not* anticipate many
>direct calls to i_foo() in any given translation unit.
We shouldn't, as a rule, second-guess the compiler unless it's show itself
to be stupid. Whether a function should be inlined or not depends a lot on
the code in a file and the processor family and type being targeted.
In my case, for example, the inlining decisions will be different when
targeting an Alpha EV4 vs an EV67. Cache size and processor speed/bus speed
ratios are different, and a good decision for one isn't necessarily the
best for the other.
Nick's talked about this a touch other places.
> > (FWIW, I was thinking of the difference between #define-ing a function and
> > just declaring it--I'd forgotten about the inline keyword)
>
>Please, let's assume `inline'.
That's fine. All the "functions" that were previously macros can be real
functions marked inline, and the compiler can choose what it does and
doesn't want to expand. We can #define in the inline, in those cases where
it's not supported. (A problem for PI to take care of on the back end)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
