Inline functions C++
Under what situations compiler decides to not "inline" an inline function in c++? Thank you.
ASKER
Andy - I am writing many classes in C++ for my new project and this answer will help me to design it more precisly. By the way, under what situations "your" compiler decides to not "inline" an inline function in c++?
Virtual functions will not be inlined. Generally functions containing loops or multiple return statements are unlikely to get inlined (that's not to say they won't be) but there are no specific rules; as Andy alludes it really is compiler specific and will also depend on what optimisation settings you enable.
Aha.
I think you might be wasting your time. You could mark small functions as inline, but the compiler might ignore it. Functions (not small) called often are probably not suitable for inlining. Functions just called once or twice you could try as inline.
I think you might be wasting your time. You could mark small functions as inline, but the compiler might ignore it. Functions (not small) called often are probably not suitable for inlining. Functions just called once or twice you could try as inline.
ASKER
Thanks evilrix for answer. Do you know or is there any URL, or document which can help me to know optimizations settings which may affect compiler's decision to inlining a certain function? To repeat myself, I am only looking for optimizations which may affect inlining. Much appreciated.
Rule of thumb.
Inlining == bigger code, more speed.
So if you want the compiler to favour using inline functions choose options to increase speed and NOT to minimise size.
Inlining == bigger code, more speed.
So if you want the compiler to favour using inline functions choose options to increase speed and NOT to minimise size.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks phoffric. Earlier answers were also good. Appreciate your time guys.
ASKER
Links were helpful have bigger picture about inlining mechanism.
ASKER
Thanks Wallymod. Got the point. As I am new to the post, I wasn't much aware of the rules. I didn't know that I can accept multiple posts. I will take care in future. As far as this question is concerned, I will stick to what I have already done as the accepted answer is the solution that helped me even if they were links. We all can google but google throws up thousands of links and its not an easy job to figure out which are more relevant and genuine so links given by experts are always a great help. To further defend myself, I have not awarded points just based on efforts, my comment was just a token of appreciation as other expert's (including evilrix) comments added value to my knowledge. Please let me know if there are still any further objections. Thanks.
The actual answer to your question was provided by my first comment and alluded to by Andy. I don't disagree that phoffric's links were helpful but you received a complete answer before then. I'm sorry you felt that the answer provided wasn't enough to answer your question, I will try to do better next time.
To recap in case something was missed; different compilers will inline differently based upon whatever optimizations the vendor has implemented and most industrial strength compilers will ignore inline in favour of what they know to be more efficiant (inline is just a hint).
The C++ Standard pretty much gives free reign to a compiler providing inlining does not cause side effects that could change behavior (hence virtual functions can't inline as they are bound late so at compile time the compiler cannot know what code to inline as it is dependent on runtime artifacts).
Other than go into specifics for a particular compiler there isn't really much else you can say.
To recap in case something was missed; different compilers will inline differently based upon whatever optimizations the vendor has implemented and most industrial strength compilers will ignore inline in favour of what they know to be more efficiant (inline is just a hint).
The C++ Standard pretty much gives free reign to a compiler providing inlining does not cause side effects that could change behavior (hence virtual functions can't inline as they are bound late so at compile time the compiler cannot know what code to inline as it is dependent on runtime artifacts).
Other than go into specifics for a particular compiler there isn't really much else you can say.
>> compiler decides to not "inline" an inline function
This question, however brief, is very sophisticated in nature. In reviewing the web for current information, there were a number of interesting ideas on this topic. For example, there were references to inlining code bloat resulting in cache misses, thereby reducing performance rather than increasing it. There were disagreements as to whether recursive functions could be inlined with the initial view being "No", until someone pointed out that they could be inlined up to a certain depth (but then the question was how to set depth compiler arguments). I believe that the concept of inlining is an ongoing optimization research field in the time-space tradeoff (and as you can see, there is a break-even point where more code for space can reduce performance).
As you can see, the concept of inlining for time optimization is certainly a non-portable issue. In my trial and error inlining approach that I mentioned, I had no illusions that when porting to another platform the previous inlining results (that were good enough to meet performance requirements) would have to be repeated again.
By trying to gather the specific ideas behind inlining, then the trial and error process in reaching suitable performance can be reached faster by the developer. (I would have done more research at the time other than my own beliefs had I not reached the performance goals relatively quickly.)
One co-worker was told to inline everything. I mentioned that this could result in slower performance, but he did what he was told, and the performance was suitable. I suspect that he could have gotten better performance had he used a different methodology, but that doesn't really matter - the view of the project manager is why spend time fine-tuning a process (given deadline pressures) if the results meets requirements.
Here's another excerpt from pros-and-cons-of-inline Oct, 2010 (fairly recent) which seems plausible:
This question, however brief, is very sophisticated in nature. In reviewing the web for current information, there were a number of interesting ideas on this topic. For example, there were references to inlining code bloat resulting in cache misses, thereby reducing performance rather than increasing it. There were disagreements as to whether recursive functions could be inlined with the initial view being "No", until someone pointed out that they could be inlined up to a certain depth (but then the question was how to set depth compiler arguments). I believe that the concept of inlining is an ongoing optimization research field in the time-space tradeoff (and as you can see, there is a break-even point where more code for space can reduce performance).
As you can see, the concept of inlining for time optimization is certainly a non-portable issue. In my trial and error inlining approach that I mentioned, I had no illusions that when porting to another platform the previous inlining results (that were good enough to meet performance requirements) would have to be repeated again.
By trying to gather the specific ideas behind inlining, then the trial and error process in reaching suitable performance can be reached faster by the developer. (I would have done more research at the time other than my own beliefs had I not reached the performance goals relatively quickly.)
One co-worker was told to inline everything. I mentioned that this could result in slower performance, but he did what he was told, and the performance was suitable. I suspect that he could have gotten better performance had he used a different methodology, but that doesn't really matter - the view of the project manager is why spend time fine-tuning a process (given deadline pressures) if the results meets requirements.
Here's another excerpt from pros-and-cons-of-inline Oct, 2010 (fairly recent) which seems plausible:
"But an inlined function puts additional pressure on the instruction cache on most modern CPUs. If your function is too large to fit in the L1 instruction cache, it may actually run slower than performing a function call (for which the CPU can optimize by prefetching the function and its return site)."
"Inlining a function may also put undue pressure on the L2 cache - if an inlined function is used an unusually large number of times, the extra code size will increase the likelihood of cache misses, leading to long delays and pipeline stalls as the CPU twiddles its thumbs waiting for the memory bus to do something."
"Inlining a function may also put undue pressure on the L2 cache - if an inlined function is used an unusually large number of times, the extra code size will increase the likelihood of cache misses, leading to long delays and pipeline stalls as the CPU twiddles its thumbs waiting for the memory bus to do something."
>> compiler decides to not "inline" an inline function
<grinning>
To be really pedantic one should look at my first comment - the only correct answer is known by the developers of the compiler, everything else here is just (informed) guesswork.
<grinning>
To be really pedantic one should look at my first comment - the only correct answer is known by the developers of the compiler, everything else here is just (informed) guesswork.
Anyway - why is that of importance to you?