| |||||||||||||
Quotes of the weekQuotes of the weekPosted Aug 23, 2012 3:16 UTC (Thu) by pr1268 (subscriber, #24648)Parent article: Quotes of the week
Andrew makes a good point. If C programmers were taught in years past to use inline in the declaration to inline the function (for efficiency reasons), then this implies that the programmers really knew what they were doing. After all, inline is a tool not to be misused. But, if contemporary C compilers override the programmers' intent1, then why bother having programmers? After all, the compiler is (obviously) smarter than the human programmer. Either that, or human programmers are notorious for misusing/abusing the tools given to them. </snide comment> 1 As I understand the Kernel menu config text, GCC ver. 4.x has an updated algorithm for determining whether inline needs to be honored. My suggestion is to evolve the compiler one step further and have it simply ignore the inline keyword. Oh, wait, does GCC do this already?
(Log in to post comments)
Quotes of the week Posted Aug 23, 2012 7:12 UTC (Thu) by dvdeug (subscriber, #10998) [Link]
If I'm looking at code that hasn't been rewritten in the past ten years, then of course the compiler is smarter then the human programmer. Even assuming that we can ignore everything but the most common desktop processor, the first AMD64 chips weren't out yet, so they had to inline based on x86, CPUs that had eight general purpose registers. The cost-benefit ratios are totally different on AMD64 then they are on x86, and if you happen to compile on ARM, MIPS, PowerPC, SPARC or any other chip, the tradeoffs there are going to be different. Unless you're thinking in assembly, the compiler knows the tradeoffs better then you, and even then you probably win only on the system you were thinking of.
Quotes of the week Posted Aug 23, 2012 7:53 UTC (Thu) by pbonzini (subscriber, #60935) [Link] In many cases, inline is ignored in the sense that the function is inlined anyway if it is small and/or called once. But there are some rare cases where you want to inline a large function, and that's where you still need the marker.But as Andrew said, it might as well be __always_inline in that case, and GCC's bag of tricks is growing with each release so as to make the annotations unnecessary in more and more cases. For example, GCC is now also able to inline only the early part of the function if there is a "return" early enough, it detects how much code will be dead after replacing constant arguments into conditionals, and so on.
Use of __always_inline Posted Aug 27, 2012 8:31 UTC (Mon) by pjm (subscriber, #2080) [Link]
> it might as well be __always_inline in that case
I wonder how long it'll be until the compiler has to start ignoring __always_inline, and introduce __really_always_inline ?
Quotes of the week Posted Aug 23, 2012 12:48 UTC (Thu) by man_ls (subscriber, #15091) [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).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.
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!
Quotes of the week Posted Aug 23, 2012 14:56 UTC (Thu) by cate (subscriber, #1359) [Link]
So let return to use again the register keyword?
I think inline is like register. Very useful if you know the target machine, but it is difficult to make a correct assessment if the same optimization should be applied to all architectures.
Quotes of the week Posted Aug 23, 2012 16:48 UTC (Thu) by zlynx (subscriber, #2285) [Link]
The register keyword is quite handy for cases where you would like it to be in a register because the compiler will prevent the programmer from messing up the possibility.
For example:
GCC does not allow the programmer to get the address of a "register" variable.
So it is like "const." It keeps you from doing something dumb.
Quotes of the week Posted Sep 3, 2012 8:37 UTC (Mon) by philomath (guest, #84172) [Link]
It's not GCC, it's the standard.
Quotes of the week Posted Sep 3, 2012 16:47 UTC (Mon) by khim (subscriber, #9252) [Link] Yup. And of course it does not work with C++ at all (that is: it's perfectly fine to take address of register variable in C++).
Quotes of the week Posted Aug 23, 2012 19:13 UTC (Thu) by vonbrand (subscriber, #4458) [Link] A long time ago, somebody told me there are three types of C compilers: Very smart ones, which disregard
register Posted Aug 25, 2012 0:00 UTC (Sat) by giraffedata (subscriber, #1954) [Link] "disregard register because ..." sounds to me like it subsumes "disregard register completely." What is the difference between the very smart and dumb compilers?
register Posted Aug 25, 2012 13:45 UTC (Sat) by mpr22 (subscriber, #60784) [Link] The dumb one doesn't store variables in registers at all (other than transiently); everything is on the stack, because that's simpler to code the compilation behaviour for.
Quotes of the week Posted Aug 30, 2012 14:07 UTC (Thu) by quanstro (guest, #77996) [Link]
so the running discussion (inline, access_once, etc)
can be summed up, is the compiler doing things /for/ me or /to/ me?
|
|||||||||||||