2 ms·
That's not what LTO is about. Most optimisations up to this point do not cross function boundaries, or file boundaries if you are lucky. This does better, allow
by koenigdavidmj 16y ago
That's not what LTO is about. Most optimisations up to this point do not cross function boundaries, or file boundaries if you are lucky. This does better, allowing optimisations to be applied across the whole program.
- malkia 16y agoAlternatively you can go "amalgated" (luajit, juce, and other projects do it). It's also called "unity" build (in game developer slang). It's not the same, because two .cpp files concatenated into one should work as they were before being split (so careful on reusing static variable names, macro defines, etc.) Also "amalgated", "unity" builds tend to make the compiler use way more memory, and reduces the possibility of spreading the compilation across many processes. Granted that latter thing is a bit of a problem by itself - for example MSVC's LTCG (Link-Time Code Generation - a whole program optimization) just produces some intermediate code in the .obj files, and maybe produces it way faster than generating real cpu code.... Then the linker takes it all and has to produce it (significantly slower linker times). With amalgated builds, at least you can divide your big project into 8 or 16 files, that compile on 8-16 processes. (JUCE splits it in four for example)