| |||||||||||||
Quotes of the weekQuotes of the weekPosted Aug 23, 2012 12:48 UTC (Thu) by man_ls (subscriber, #15091)In reply to: Quotes of the week by pr1268 Parent article: Quotes of the week Ideally the human programmer would be freed from the mundane task of having to figure out if inlining a function is worth it or not, and would employ any spare time in more interesting stuff (like providing more or better features). Also, the compiler is programmed by another human: it's not human vs computer but rather a case of specialization. When a problem such as inlining can be solved once and for all by a specialized team, I would always say go for it. Morton is just asking for clear rules about what cues the compiler really needs; I am not sure if his tone includes some sort of whining.
(Log in to post comments)
Quotes of the week Posted Aug 23, 2012 20:26 UTC (Thu) by cmccabe (guest, #60281) [Link]
> Ideally the human programmer would be freed from
> the mundane task of having to figure out if > inlining a function is worth it or not, and > would employ any spare time in more interesting > stuff (like providing more or better features).
Well, there is a simple solution to that: don't use the inline keyword(s). Or better yet, don't use C-- use a higher-level language instead.
Independently of that, what modern compilers have done with the traditional inline keyword is ridiculous. The behavior is worse than compiler-specific: it's compiler-version-specific, and nobody can explain what exactly it does, if anything. I agree with Andrew: use nothing, or use __always_inline.
Quotes of the week Posted Aug 25, 2012 3:56 UTC (Sat) by daglwn (subscriber, #65432) [Link]
> Independently of that, what modern compilers have done with the
> traditional inline keyword is ridiculous.
Of course it isn't. I don't think you quite appreciate how difficult it is to get inlining right. Do too much and you blow the instruction cache or create too much register pressure. Do too little and you unnecessarily inhibit program transformation.
It's a very tricky balance, one that must be maintained differently not only based on target architecture but also on input language.
Compilers change inlining so frequently precisely because they get better and better at generating code.
Quotes of the week Posted Aug 25, 2012 22:50 UTC (Sat) by lindahl (subscriber, #15266) [Link]
Treatment of "inline" is the same as how compilers treat "register" declarations and loop-unrolling pragmas -- after a few years of cpu evolution and compiler improvements, these hints are always wrong.
And those pesky customers who care about performance expect the compiler to DTRT despite all the bogus "inline", "register" declarations, and loop-unrolling pragmas scattered all over their code.
Quotes of the week Posted Aug 29, 2012 23:59 UTC (Wed) by epa (subscriber, #39769) [Link]
#define inline __always_inline?
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!
|
|||||||||||||