LWN.net Logo

Quotes of the week

Quotes of the week

Posted Aug 29, 2012 23:59 UTC (Wed) by epa (subscriber, #39769)
In reply to: Quotes of the week by cmccabe
Parent article: Quotes of the week

#define inline __always_inline?


(Log in to post comments)

The compiler is your friend

Posted Aug 30, 2012 0:10 UTC (Thu) by man_ls (subscriber, #15091) [Link]

Why not learn to stop worrying and love the compiler? Leave the pesky business of determining whether a particular function must be inlined (on a particular combination of architecture and processor) to your friendly compiler.

From my remote days as a C developer I remember that there was an insane pleasure in trying to optimize every little bit out of the tools, but nowadays it makes less sense than ever, what with smart compilers and link time optimizations and branch prediction and steady improvements in processors every couple of years. Specially in the Linux kernel, targeting ARM SoC's and 32-processor boxes with the same code, and having to maintain it for decades, it is really hard to see the point to inline by hand.

The compiler is your friend

Posted Aug 30, 2012 13:41 UTC (Thu) by epa (subscriber, #39769) [Link]

I believe that the kernel developers, being on average more experienced and skilled than the average programmer, sometimes have legitimate reasons to override the compiler's judgement and force functions to be inlined. I expect that if the kernel could be compiled with profiler feeedback (so you compile once, run a test load, then re-compile optimizing based on that run) then the compiler could make almost perfect decisions about inlining. Purely based on static analysis it is unrealistic to expect the compiler to out-guess a skilled programmer all the time, though it may do so in 95% of cases.

Obviously, whether to inline a function would have to be considered separately for each processor family.

The compiler is your friend

Posted Aug 30, 2012 15:14 UTC (Thu) by viro (subscriber, #7872) [Link]

Because gcc main uses are *not* in "we have less than 8Kb of stack and that's _it_ - overflow it and you are dead" kind of situation. The kernel, OTOH, is, and there's nothing we or gcc folks can do about that. And no, it's not something you can realistically cure with an option controlling how optimizer works; you'll have it rotting all the time, not to mention the nightmare it would be to maintain it on the gcc side.

So no, you can't just trust the compiler to DTRT, since for most of its users the right thing is seriously different. We are overusing inline, no arguments about that, but it's not as simple as "just let the compiler choose".

The compiler is your friend

Posted Sep 5, 2012 15:32 UTC (Wed) by epa (subscriber, #39769) [Link]

FWIW, they are not 'inlining by hand'. That would involve manually pasting in the code where needed. Instead you write the function as normal and then, if you wish it to be inlined, ask the compiler to do that. The compiler is your friend!

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds