On Mon, Oct 10, 2011 at 2:32 AM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
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 otherwise).
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 interested...
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 debugger.
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, - Jeff