Printable View
Can anyone provide me with an example of an inline function that actually hinders or helps? I was just implimenting a function, which I deemed worthy of being inline but I was then thinking, "does this indeed actually help? In fact, when ever could it help?"
I'm just curious, if anyone has any examples, links and or data I'd much like to see it.
This article is a little out of date, but it shows amazing things that are only possible through forcing the compiler to inline stuff...
http://www.flipcode.com/articles/art...ctormath.shtml
It's a bit extreme though as I imagine you only want a simple example...
inlining always helps speed up the program, but it may also make the program larger. Whether it helps or not depends on what you want to do -- do you want the fastest running program or do you want the smallest program size. Normally one-statement functions should be inlined. There is no guarentee that the compiler will actually inline the function even if you use the inline keyword -- compilers only treat that keyword as a suggestion and it is free to do whatever it wishes.
> inlining always helps speed up the program
That's an overly bold statement.
But yes, leave the compiler to worry about inlining, and leave the decision until you've had a chance to do some profiling on a real finished and working program with real data.
That's just false, though.Quote:
Originally Posted by Ancient Dragon
Many modern compilers automatically inline functions if you use them a lot (especially if you optimise for speed). So inlining a function might not do anything because it's already inlined! Compilers are free to ignore the inline keyword, too, and I'm sure some do.Quote:
inlining always helps speed up the program
Nothing false about it. When the program does not have to call a function then it makes the program a tad bit faster. So where is the folly in that statement? This is not the same as saying the inline keyword will always produce inline code -- that is false as I also mentioned in my post.Quote:
Originally Posted by Rashakil Fol
Well, duua! we are talking about inlining verses not inlining. inlined functions will ALWAYS make the program run faster than functions that are NOT inlined. This has nothing at all to do with whether the compiler does or does not honor the inline keyword.Quote:
Originally Posted by dwks
Except massively unrolled code might no longer fit in the cache.
A cache miss to code which isn't yet in cache (or worse, not even in memory) is going to be a lot worse than some nice tight code which has a few function calls, but it small enough to remain cache-resident all through its run.
>> Many modern compilers automatically inline functions ... Compilers are free to ignore the inline keyword, too, and I'm sure some do.
That just makes me wonder this - why did they bother making the inline keyword if the compiler chooses whether or not it is to be used? (I'm only being slightly sarcastic) They probably to do with the number of extra-marital kids the time ... right, Mario? Or is that just for size_types ;) if the number of times the function is called exceeds the former number, it's inlined, else it's not.
Is it faster at building the exe when the functions are inlined, or if they aren't?
It's probably like the register keyword. It was a good idea at the time but someone realized that the compiler is better at the job than programmers. :)Quote:
Originally Posted by twomers
Inlining puts an optimization choice in the coder hands. The optimization comes from the fact that at runtime it's possible to avoid the extra cost of a function call. The keyword exists because there are tradeoffs. The most common one is an increase in file size. As such, the decision is left to the programmer to optimize or not.
It's important to understand that the decision to inline or not is not of the compiler. We speak "the compiler refuses to inline", when in fact probably the more correct way would be "the compiler can't inline". Some functions simply cannot be inlined (imagine a complex recursive function), others would lead to massive changes in code that would not respect anymore the original source.
However, I would do it differently. If I developed a compiler I would code in decisions to inline or not according to my mood. I don't know... like if an extra-marital kid suddenly showed up at my door.
It's not just false because you could totally flush out the cache (but that's a reason), it's false because function calls are not necessarily more expensive. You can take a function that makes 100 function calls to another and move for loops around so that now you're making 10000 function calls, only to have the version with more function calls run faster. You could do this directly in assembly language and see the result. Or you could get the opposite result.Quote:
Originally Posted by Ancient Dragon
People get all jyzed up about function calls, but ultimately, it amounts to pushing one or two pointers onto the stack, and accessing the argument list in the child function. All these are operations in the closest cache to the processor, so these are fast. With all the instruction reordering and crazy stuff that processors do these days, the time you spend pushing the stack might have been spent waiting for addition circuits to clear out anyway, and the way instructions are aligned to word boundaries will have interesting effects.
Of course, inlining is still a Good Thing.
How am I the first one to post this in the thread?
Because you beat me to it.