Re: [boost] Is there a special reason to use inline before template functions?

Subject: Re: [boost] Is there a special reason to use inline before template functions?
From: Brian Ravnsgaard Riis (brian_at_[hidden])
Date: 2008-12-09 14:02:39

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Marcin wrote:
> Brian Ravnsgaard Riis wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Michael Marcin wrote:
>>> Thomas Klimpel wrote:
>>>> I would expect that current compilers know better when inlining a
>>>> function provides a benefit than the programmer.
>>> They don't.
>>
>> This is really sorta off-topic here, but I find that statement hard to
>> believe. Can you in any way substantiate that argument? I personally
>> *never* use the keyword inline, since the compiler is free to ignore it,
>> and may choose to inline functions I have not declared inline.
>>
>> What little I do know about compiler internals would lead me to believe
>> that they could - and should - indeed know better than the programmer
>> when it makes sense to inline a function.
> 
> The compiler can know a lot but it can't know how often code is called
> when calling the code is the result of data or user input.
> 
>>
>> To complicate matters further, inlining a given function may make sense
>> in certain contexts but not others. I believe Herb Sutter has given the
>> subject thorough treatment some years gone. Nothing I have experienced
>> has caused me to doubt his words in this matter.
>>
> 
> Inlining is a low level optimization and like all such optimizations
> they should only be done after the correct algorithms, abstractions, and
> representations are in place with the aid of profiling.

Indeed. The compiler may still ignore it, though.

> 
> That being said I worked on a embedded project that needed to render 3d
> in software in realtime. We made heavy use of boost, templates, classes,
> and metaprogramming. In the rendering code especially controlling which
> functions were expanded inline and which were function calls was the
> difference between having a product which could ship and one that was
> too slow to pass cert. Luckily we were able to give the compiler enough
> information to choose which functions to inline because the language
> gives us the tool to do so, the inline keyword.
> 

So, there was a good argument after all! :-D I was hoping you would come
back with something more descriptive than "They don't." I think it was
the terseness of it I frowned upon.

Of course, after profiling, applying a hint to the compiler about
inlining may indeed be in order. I still think it is a rare thing that
you should second-guess your compiler, but I'll admit that it can have
its uses. Actually, I think I would prefer inlining a specific function
*call* if that were possible, not the function, but...

Heading seriously off-topic here... Thanks for your replies, Dave,
Jonathan and Michael. I got the "discussion" I was hoping for. :-)

 /Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJPsDPk1tAOprY6QERAuHUAKDNq00v+1nYEaoom/n23+GBbr2U8ACdFA5W
40tXjmdeNNkZACm78s3m76M=
=qUM4
-----END PGP SIGNATURE-----