Subject: Re: [boost] BOOST_FORCE_INLINE
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-10-10 16:09:56
On Mon, Oct 10, 2011 at 2:32 AM, Mathias Gaunard <
> On 10/10/2011 10:46, Domagoj Saric wrote:
>> On 10.10.2011. 8:22, Jeffrey Lee Hellrung, Jr. wrote:
>>> +1, my thoughts exactly, Beman. Can anyone provide any links to a case
>>> study or something similar investigating the effects of forcing inlining?
>>> I'm definitely interested to see what real effects this could have.
>> Well Mathias has already outlined the major reasons. That seems like
>> quite sufficient documentation. If a developer is performance conscious
>> and notices one the outlined problems in the codegen he can simply try
>> the force inline approach and see if it helps. I don't see where a
>> problem could lie there or a reason for wasting too much time discussing
>> something so simple. Otherwise one could question any existing part of
>> the language by pointing that it could be abused (unintentionally or
>> I don't know of a "study" related to forceinline, but in this case it
>> arose as a (partial) solution to the problems listed by Mathias in the
>> development of the NT2 (and thuse Boost.SIMD and Boost.Dispatch)
>> libraries. These were discussed on the NT2 dev mailing list an on #nt2
>> so maybe someone can present logs of these discussions if you are
> Boost.SIMD is particularly sensitive to inlining.
> The arguments of each function should be put into SSE registers, but when a
> function is not inlined, the registers are copied to the stack and the
> addresses on the stack are passed to the function.
> The ABI forces this behaviour because the types used to represent the
> registers are structures.
> On another note, inlining stuff has proven useful to ignore a certain
> amount of function jumping with Boost.Dispatch when running code in a
Don't get me wrong, I'm sure it's necessary from time to time! Just looking
to see what additional wisdom the Boost community can impart regarding its
use. Thanks for the follow-ups,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk