7 ms·
The link-time optimizations seem useful - not only can the output code run faster, but the compilation is in parallel. Has anyone tried it? g++ is a fast comp
by alec 16y ago
The link-time optimizations seem useful - not only can the output code run faster, but the compilation is in parallel. Has anyone tried it? g++ is a fast compiler and it's easy to parallelize on files, but making the linker faster/parallel sounds like a big deal.
- koenigdavidmj 16y agoThat'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)