I've working on a project at work where there's loads and loads of code in the header files. If I were using Visual Studio this wouldn't be an issue, as this has pre-compiled headers etc, but this is Linux GCC code.
Anyway, its starting to become a bit of an issue with compilation times. Of course the templates are going to have to remain in the headers etc, but most of this code could be extracted into implementation files and linked against as a static library. All of the projects uses these headers and get compiled each time, so it makes sense to create a static lib.
Implementations in the header files are in-lined, or is this only a hint, like the inline keyword? This code is VERY time critical and I'm concerned about moving the implementations out of the headers. Can I achieve the same thing if I use the inline keyword as opposed to having implementations in header files?
** UPDATE **
I know that inline is only a hint to the compiler. I'm not in control of everything in the project and I just want to move everything out of the headers into a library without affecting performance. Is this actually going to be a try it and see thing? I just want to keep performance exactly the same but enhance compile time.
The inline keyword is only a hint to the compiler that it may wish to inline that function. Its real purpose is to allow you to legally "violate" the one definition rule.
In order to inline a function its body has to be visible at the point of call, which typically means that if you move the function to an implentation file it may not be inlined anymore.
But keep in mind that most likely large functions in the header will not be inlined anyway. Also consider that in many cases inlined functions may actually be slower than called functions due to a variety of architecture-specific issues.
inline is a hint for optimization, but it is also used to work around ODR.
Consider using whole program optimization / link-time optimization instead. It allows you to have implementation in multiple files and basically everything has the same opportunity to be optimized (and inlined) as if it were in the same translation unit.
Your compile times become much quicker, but link times usually suffer, sometimes quite a bit. You don't need to enable it for debug builds though, so it can manifest a pretty immediate improvement to dev time.
If I were using Visual Studio this wouldn't be an issue, as this has pre-compiled headers etc
GCC has them too.
http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
The inline keyword does NOT mean that the function has to be implemented "in the line" where you define the function. As you know it is a hint for the compiler, to let it try compiling as if the few lines in the function were at the place where you call it. Thus avoiding the overhad of saving the adress to jump back, a vtable lookup etc.
Thinking it is faster called because it is in the header, is wishfull thinking (of the original guy who wrote the code).
Try it and move the implementation to the cpp file in a minimal example - main one object one inline function one call to it. Once implemented in the header and once in a cpp file. Then look at the assembly. No difference.
Related
I have some small utility functions (< 20 lines of code per function) that I am currently putting in a utils.h file with the keyword inline in front of them so I don't run into multiple definition linking errors. This is what I have always done for small functions.
I am wondering what the advantages and disadvantages are to:
Using my method
Putting the function declarations in utils.h and definitions in utils.cpp
Disadvantage of inline:
If the header is included into many TU, the build time is slowed due to building of the function for each TU (this may be diminished if pre-built header is an option).
When you make any change to the implementation, then all TU that include the header must be re-compiled. This is especially bad if the implementation changes often (bugs, new features, etc.) and when the header is used in many TU.
If the implementation depends on any definition / declarations, then those dependencies transfer to all TU that include the header. This increases the time to build those TU and spreads the rebuilding caused by changes to the dependencies too. If the dependencies are system specific, then this complicates compatibility between systems.
Advantages of inline:
If you reduce the number of TU; then build time from scratch improves.
It allows inline expansion to the TU that include it (but that is also allowed by using link time optimisation).
For header vs. source there is a HUGE speed difference for small functions here. Basically anything that the compiler would always inline is a good candidate to be in the header.
The potential gains inlineing gives you come at the cost of compile time. It can also be nice for debugging purposes to have an actual function that gets called in the binary where you can set a breakpoint.
Generally if the function it not called often then put it in the source file, it's just neater and nobody cares. Especially something with 20 lines excluding boiler plate. That's not really small. Only put stuff in the header that is time sensitive.
And do check out if your compiler can do LTO (link time optimization). Because with that you can have functions in the source and still get them inlined when you use LTO. But while developing you can compile without LTO and get quick builds (and slower binaries). So with LTO you can have your cake and eat it too.
Overall I would draw the line for functions in headers far lower than 20 lines. If your function only has a return statement then put it in the header, otherwise the source, and use LTO. That's my rule-of-thumb.
I am aware that the keyword inline has useful properties e.g. for keeping template specializations inside a header file.
On the other hand I have often read that inline is almost useless as hint for the compiler to actually inline functions.
Further the keyword cannot be used inside a cpp file since the compiler wants to inspect functions marked with the inline keyword whenever they are called.
Hence I am a little confused about the "automatic" inlining capabilities of modern compilers (namely gcc 4.43). When I define a function inside a cpp, can the compiler inline it anyway if it deems that inlining makes sense for the function or do I rob him of some optimization capabilities ? (Which would be fine for the majority of functions, but important to know for small ones called very often)
Within the compilation unit the compiler will have no problem inline functions (even if they are not marked as inline). Across compilation units it is harder but modern compilers can do it.
Use of the inline tag has little affect on 'modern' compilers and whether it actually inlines functions (it has better heuristics than the human mind) (unless you specify flags to force it one way or the other (which is usually a bad idea as humans are bad at making this decision)).
Microsoft Visual C++ was able to do so at least since Visual Studio 2005. They call it "Whole Program Optimization" or "Link-Time Code Generation". In this implementation, the compiler will not actually produce machine code, but write the preprocessed C++ code into the object files. The linker will then merge all of the code into one huge code unit and perform the actual compilation..
GCC is able to do this since at least version 4.5, with major improvements coming in GCC 4.7. To my knowledge the feature is still considered somewhat experimental (at least in so far as many Linux distributions not using it). GCC's implementation works very similarly by first writing the preprocessed source (in its GIMPLE intermediate language) into the object files, then compiling all of the object files into a single object file which is then passed to the linker (this allows GCC to continue to work with existing linkers).
Many big C++ projects also do what is now being called "unity builds". Instead of passing hundreds of individual C++ source files into the compiler, one source file is created that includes all the other source files in the project. The original intent behind this is to decrease compilation times (since headers etc. do not have to be parsed over and over), but as a side-effect, it will have the same outcome as the LTO/LTCG techniques mentioned above: giving the compiler perfect visibility into all functions in all compilation units.
I jump between being impressed by my C++ compiler's (MSVC 2010) ingenuity and its stupidity. Some code that did pixel format conversion via templates, which would have resolved into 5-10 assembly instructions when properly inlined, got bloated into kilobytes(!) of nested function calls. At other times, it inlines so aggressively that whole classes disappear even though they contained non-trivial functionality.
This depends on your compilation flags. With -combine and -fwhole-program, gcc will do function inlining across cpp boundaries. I'm not sure how much the linker will do if you compile into multiple object files.
The standard dictates nothing about how a function can be inlined. And compilers can inline functions if they have access to their implementation. If you only have a header with binaries, it would be impossible. If it's in the same module, the compiler can inline the function even if it is in the cpp file.
I've been trying to make an attempt to make a Game Engine, and I started out by making the Mathmatical foundation ( Vector, Matrix and Point classes. )
I would like to make a static library file (.lib) which I can then use in the rest of my Game Engine where it's needed.
What I was wondering is the following. Since most functions in the library need to be as fast as possible. I'd like to see the functions for example a Vector class being inlined. Can the compiler automatically do this? Or is some kind of hint needed?
I know I can put all the source in the header files but I think that's not really an elegant solution since some functions might be too large to be inlined. ( Header files wouldn't kind of be messy for the poeple using them. )
I hope you guys could help me out.
Christian
Inlining of functions is only guaranteed to work with current compiler technology if the compileunit has visibility of the source code. Once you compile code into a library, it will not inline the function, no matter what the function does.
There is some "whole program optimization" schemes (available in at least MSVC and GCC, probably other compilers too) that produce a "object file" that is only part of the way to machine-code, so that some of the information about "what the source code wanted" is available to the final code-generation/linking stage to move code around, perform inlining and such, but this is only applicable when all source-files are available at the compile-time. Once something is made into final object code (which your static library is), it won't be making it into the "inliner" part.
Obviously, if you have classes, they will be in header files, so if you put functions suitable for inlining into the header file, the compiler will do the right thing.
Yes, you can do this with link time optimization. If you generate a "fat" library, it would include both the compiled source and also an intermediate form that can be used to inline functions at link time (essentially, at link time a final compilation step is done, where everything is visible).
The technique is somewhat fragile since you need to ensure you are using the same flags at compile and link time and there are a few other restrictions: it wouldn't be a good way to publicly distribute a library. If it's for a controlled internal use though, it may work well.
I have a big class with lots of utility functions. those functions are very small and I would like them inlined.
The problem is they are all in a source file and should stay in the source file and not move to the header file (so I don't need to recompile everything every time one changes).
If I mark them as inline I get
symbols not found
Is there a way to make them inline or do I need to blindly trust the link time optimizer?
I need the code to be portable between clang 3 and gcc 4.6, but #defines based on compiler will be ok (so answer how to do it only in one of the compilers is fine too).
[These] functions are very small and I would like them inlined. [But] I don't [want] to recompile everything every time one changes.
You can't have both of these things. If a function is inlined, then you have no choice but to recompile all its callers when it changes. That's how inlining works. Even if you used a link-time optimizer to do it automatically at link time, you would still be paying the compilation-time cost of reprocessing all the callers.
AFAIK neither gcc 4.6 nor clang 3 have link-time optimizers that are up to scratch, by the way.
Editorial aside: No compiler that I know of has heuristics that are good enough to make manual inline annotations unnecessary, yet. Even VS2010, which I mentioned in the comments as an example of a link-time optimizer that is up to scratch, still needs quite a bit of advice about what to inline.
Place the implementation in an .inl file. Have only the necessary .cpp files #include it. This way changes to the implementation (touch .inl file) trigger recompile only of the dependent .cpp file. Changes to the definition (touch the .h file) trigger recompile of all files consuming the declaration.
This is a common practice for both inline functions and for template implementations. .inl files should be viewed basically as 'included cpp' files.
If you want a function to be inline'd you have to place it in a header file, unless it's only being used in the same source file. The reason being that the compiler needs the actual function definition in order to place the definition "inline" wherever it's being called, and then compile it up.
You can find further information: here and here.
You need the function mandatory inlined - you place it in the class definition.
One option could be to place the inline functions in a precompiled header file, which will speed up the compilation. But because of the nature of inlining functions all places they are used will have to be recompiled.
http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html
Visual studio allow you to create "inlined" classes (if I am not mistaken with the name).
So class header and implementation all in one file.
H. file contain definitions and declarations of the class and functions, there is no .cpp file at all.
So I was wondering if there is any penalty for doing it that way? any disadvantages ?
Thanks a lot
any penalty for doing it that way? any disadvantages?
Yes. If you need to change the implementation of the class, since this is in a header file, all users of the class need to recompile, even though they should only be concerned with the interface. For some projects, this can be quite expensive.
You can put the complete implementation of a class in the header with any compiler. There's usually a penalty in terms of compile time -- the header will be compiled separately for each source file that includes it.
There may be a penalty in terms of code bloat as well -- putting the function definitions inside the class definition implicitly declares them inline, so there may be an increased likelihood of the compiler generating code for each of them individually instead of generating code in one place, and generating calls to it elsewhere.
A pretty bad idea if you ask me, especially for big projects. Take a look at Lakos' "Large-Scale C++ Software Design" to learn more about the drawbacks of such approach.
There's another potential penalty: Performance.
If you make too many functions inline, this leads to code bloat, which results in executables which functions and loops may not fit into the instruction cache of the target CPU.
No penalty.
But it also does not mean that the code is actually inlined.
They inline keyword is only a compier hint that is usually ignored as the compiler is usually much smarter than the developer in terms of knowing when to inline code.
The inline keyword is only a hint to the compiler to inline code. Visual Studio has a __forceinline specifier for functions that would make the compiler forcibly inline the function without a cost/benefit analysis.
About __forceinline : http://msdn.microsoft.com/en-us/library/z8y1yy88.aspx
The *.h file having all the definitions and declarations should not make any difference though except for compile times for large files.
There are two "penalties"
One will be assessed at compile time. If you have an unusually large project, you'll have lots of header files that the preprocessor will expand into one another with much more code. Changing one .h file will trigger a recompilation in all the files that include it.
The other is that it (may possibly) lead to larger binaries because that code is replicated in other object files.