inline vs. function pointers

[jacob navia]

Le 28/01/11 21:01, Ian Collins a écrit :

Hang on, so you don't do any checking to see if a function should be
inlined? Say someone declared a 2000 line function 'inline', would you
still inline it?

I do not see what the size of the function has to do with generating or
not a function for inlined ones...

In any case I *do* check for size.

 

[Willem]

Ian Collins wrote:
) For larger function the overhead is noise.
)
) Determining which functions are suitable for inline is an increasingly
) complex optimisation. In the days before caches, it was a size/space
) trade off. With modern processors and operating systems, over
) aggressive inlining can force a function out of the cache, or force
) unnecessary page faults. So the inline heuristic isn't trivial which is
) one reason compilers employ techniques like profile feedback
) optimisation to determine the best combination.

So, if somebody specifically marks a function 'inline', doesn't that mean
that that somebody wants to tell the compiler that it shouldn't decide
for itself to inline it or not ?

Also, I'm not sure what the actual wording is, but if you say
"to make *calls to* the function as fast as possible", then you
could argue that that's not about the time spent inside the function,
but about the time it takes to go to and from it.

Anyway, inlining large and complex functions could be very worthwile
if they're called with constant arguments. That would create opportunities
for a lot of constant folding, and may even lead to whole pieces of code
being trimmed because they're not being used. So, in that light alone,
being able to force a compiler to inline a function would be a plus.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[lawrence.jones]

Seriously, I don't think you need to worry about that; inline is
too generally useful to be made optional. (Not speaking for the
committee, of course.)

Not to mention that, since it doesn't actually have to do anything, it's
almost trivial to implement.

 

[lawrence.jones]

Hang on, so you don't do any checking to see if a function should be
inlined? Say someone declared a 2000 line function 'inline', would you
still inline it?

And what happens when an inline function calls itself recursively?

 

[Willem]

Ian Collins wrote:
) True, but it might also have a negative effect. Or be a big win on one
) CPU, but a big loss on another (under the same OS). Nowadays I prefer
) to let the optimiser deal with these complexities. If performance is a
) real issue, I'd use profile feedback on the specific processor I'm
) targeting.

To me, that is an argument *for* having the inline keyword force inlining
of the function. Not giving the inline keyword indicates that you prefer
to let the optimiser deal with it.

Suppose you need the performance, and profiling turns out that inlining is
a speed win, then wouldn't it be a slap in the face if the compiler decides:
"The function is marked inline, but I don't feel like it, so let's not."


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[robertwessel2]

Ian Collins wrote:

) True, but it might also have a negative effect.  Or be a big win on one
) CPU, but a big loss on another (under the same OS).  Nowadays I prefer
) to let the optimiser deal with these complexities.  If performance is a
) real issue, I'd use profile feedback on the specific processor I'm
) targeting.

To me, that is an argument *for* having the inline keyword force inlining
of the function.  Not giving the inline keyword indicates that you prefer
to let the optimiser deal with it.

Suppose you need the performance, and profiling turns out that inlining is
a speed win, then wouldn't it be a slap in the face if the compiler decides:
"The function is marked inline, but I don't feel like it, so let's not."

Inline must be no more than a hint and cannot be unconditional. Just
think of what would happen if you declared a recursive function inline.

 

[Nick Keighley]

And what happens when an inline function calls itself recursively?

depends if its tail recursive

 

[Malcolm McLean]

Hang on, so you don't do any checking to see if a function should be
inlined?  Say someone declared a 2000 line function 'inline', would you
still inline it?

Depends on the machine code, but normally the call/return structure is
something to help human programmers organise code, not something the
machine needs. Even if the function is called in multiple places the
code bloat is unlikely to be significant - 2000 lines will compile to
a few thousand instructions, so tens of kilobytes machine code. Not
much if you've 2GB to play with.

 

[Ian Collins]

Depends on the machine code, but normally the call/return structure is
something to help human programmers organise code, not something the
machine needs. Even if the function is called in multiple places the
code bloat is unlikely to be significant - 2000 lines will compile to
a few thousand instructions, so tens of kilobytes machine code. Not
much if you've 2GB to play with.

But you don't have 2GB of cache!

 

[luser- -droog]

And what happens when an inline function calls itself recursively?

Couldn't you handle it just like entering a new block?
make a local variable frame and jump to the top?
Oh, wait, nevermind. How would you get back again?

 

[Willem]

christian.bau wrote:
) Well, this is rubbish. If I have a 2000 line function, and then write
) a fifty line function that calls the 2000 line function 50 times, and
) then write another fifty line function that calls the previous
) function inline, and then twice more, then your compiler will just
) crash without any good reason.

No, it will crash because you *SPECIFICALLY TOLD* the compiler
to inline all those function calls.

) And if I just have a function that does fifty calls in a row to the
) 2000 line function, then the code will probably run ten times slower
) because it overruns all caches.

Irrelevant. If the programmer specifically requests that a function
be inlined, then who is the compiler to question that request ?

If the code runs ten times slower because the programmer added an inline
keyword in the wrong place, then that's *the programmer's fault*.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Malcolm McLean]

In other words, we don't need optimising compilers because processors
are fast enough.

Well, this is rubbish. If I have a 2000 line function, and then write
a fifty line function that calls the 2000 line function 50 times, and
then write another fifty line function that calls the previous
function inline, and then twice more, then your compiler will just
crash without any good reason.

And if I just have a function that does fifty calls in a row to the
2000 line function, then the code will probably run ten times slower
because it overruns all caches.

 

[Malcolm McLean]

And if I just have a function that does fifty calls in a row to the
2000 line function, then the code will probably run ten times slower
because it overruns all caches.

These sorts of micro-optimisation tradeoffs change all the time. You
might be right today, wrong on the next processor to be produced.

 

[James Kuyper]

christian.bau wrote:
) Well, this is rubbish. If I have a 2000 line function, and then write
) a fifty line function that calls the 2000 line function 50 times, and
) then write another fifty line function that calls the previous
) function inline, and then twice more, then your compiler will just
) crash without any good reason.

No, it will crash because you *SPECIFICALLY TOLD* the compiler
to inline all those function calls.

No, he did not, the "inline" keyword does not request that the function
be inlined. It "suggests that calls to the function be as fast as
possible". If inlining a particular function would make it slower, then
for that particular function, the "inline" keyword is a suggestion that
inlining NOT be performed, counterintuitive though that may seem.
It's just a suggestion, so failing to honor would not render the
compiler non-conforming; but it counts as poor QoI.

) And if I just have a function that does fifty calls in a row to the
) 2000 line function, then the code will probably run ten times slower
) because it overruns all caches.

Irrelevant. If the programmer specifically requests that a function
be inlined, then who is the compiler to question that request ?

C does not provide a keyword for requesting that a function be inlined;
the 'inline' keyword is certainly not such a keyword; as shown above, it
sometimes explicit suggests that the code NOT be inlined. If a new
keyword were created for requesting inlining, regardless of the effect
on the speed of the code (perhaps it could be called
_inline_even_if_slower), then use of that keyword would carry the
implications you've mistakenly concluded about the "inline" keyword.

 

[Ian Collins]

These sorts of micro-optimisation tradeoffs change all the time. You
might be right today, wrong on the next processor to be produced.

ten times slower != micro-optimisation trade-off.

That is why it is best to leave the choice of what to inline to the
compiler.

 

[Joel C. Salomon]

Inline must be no more than a hint and cannot be unconditional. Just
think of what would happen if you declared a recursive function inline.

The inline specifier doesn't mean "always expand this function in-line"
for exactly that reason. For recursive functions a plausible
interpretation might be "use tail-call optimisations". Or "sorry, boss;
I'm already going as fast as I can."

--Joel

 

[Malcolm McLean]

ten times slower != micro-optimisation trade-off.

That's a common misconception. Micro-optimisation refers to the type
of optimisation (the scheduling of machine code instructions, as
opposed to algorithmic optimisation - reduction of the big-O runtime
of the algorithm or precalculation of results). Not to the percentage
speed-up obtained.