4 ms·

Out of these, I found the ThinLTO [0] most interesting. It's an effort to solve issues with long build times and high memory consumption associated with link ti

by exDM69 10y ago

Out of these, I found the ThinLTO [0] most interesting. It's an effort to solve issues with long build times and high memory consumption associated with link time optimization. Early benchmarks show perf results that are almost on par with full LTO and compile times near plain old -O2. LTO is the compiler feature I'm waiting to become mainstream. Without it you have to make compromises with translation units (put more stuff in headers than you'd want to) to get the performance you want. [0] http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html?m=1 http://blog.llvm.org/2016/06/thinlto-scalable-and-incrementa...

vvanders 10y ago
Oh man LTCG on MSVC was brutal on build times. I remember we had to use it extensively in games since we'd usually be within 3-5mb of system limits on a release console. If LTO is similar that sounds like a massive win and something to look forward to. [edit] Looks like LTO is more about performance than perf+binary size. Still sounds like awesome stuff.
- DannyBee 10y ago
  Just to clarify: LTO is what most other compilers (including LLVM) call what LTCG is in MSVC. ThinLTO is a very different LTO model than "standard LTO". The ThinLTO slides go over the various LTO models that exist. Previously, before Google built ThinLTO, we built LIPO (and WHOPR) for GCC, https://gcc.gnu.org/wiki/LightweightIpo https://gcc.gnu.org/wiki/LightweightIpo Google isn't going to use GCC as it's compiler anymore, and in fact, has mostly moved off it. We needed to replace LIPO, so we built ThinLTO. The problem with LTO models in general (as the thinlto slides go over) is how to make it scalable. Part of that is memory, part of it is parallelization, part of it is optimization/analysis speed. THe memory issues are about how memory efficient the IR is and how demand driven IPO is. IE can your whole-program analysis go function by function, without it taking a lot of time and memory to import individual functions (and throw them away if you need to). Most LTO is slow because it tries to keep large parts of the program in memory at one time, and has no good way of being as lazy as possible about pieces of the program. The parallelization issue is "what is being serialized to make LTO work". Some compilers parallelize the backend code generation, some parallelize nothing. There is often still a lot of serial stuff (global analysis, etc). The CPU time issue is how fast you perform analysis and can generate code. ThinLTO is meant to allow you to parallelize basically every step, import exactly the parts of the program you want at a given time in a quick and memory efficient way, etc.
  - vvanders 10y ago
    Thanks for the clarification and detailed breakdown. Makes a lot of sense. Back when we'd use LTCG it was a ~30 minute link time penalty which prohibited it from all but the final release builds. Seeing this stuff move forward to be more effective to use is a great improvement.

by exDM69 10y ago

vvanders 10y ago

Oh man LTCG on MSVC was brutal on build times. I remember we had to use it extensively in games since we'd usually be within 3-5mb of system limits on a release console. If LTO is similar that sounds like a massive win and something to look forward to. [edit] Looks like LTO is more about performance than perf+binary size. Still sounds like awesome stuff.

DannyBee 10y ago
Just to clarify: LTO is what most other compilers (including LLVM) call what LTCG is in MSVC. ThinLTO is a very different LTO model than "standard LTO". The ThinLTO slides go over the various LTO models that exist. Previously, before Google built ThinLTO, we built LIPO (and WHOPR) for GCC, https://gcc.gnu.org/wiki/LightweightIpo https://gcc.gnu.org/wiki/LightweightIpo Google isn't going to use GCC as it's compiler anymore, and in fact, has mostly moved off it. We needed to replace LIPO, so we built ThinLTO. The problem with LTO models in general (as the thinlto slides go over) is how to make it scalable. Part of that is memory, part of it is parallelization, part of it is optimization/analysis speed. THe memory issues are about how memory efficient the IR is and how demand driven IPO is. IE can your whole-program analysis go function by function, without it taking a lot of time and memory to import individual functions (and throw them away if you need to). Most LTO is slow because it tries to keep large parts of the program in memory at one time, and has no good way of being as lazy as possible about pieces of the program. The parallelization issue is "what is being serialized to make LTO work". Some compilers parallelize the backend code generation, some parallelize nothing. There is often still a lot of serial stuff (global analysis, etc). The CPU time issue is how fast you perform analysis and can generate code. ThinLTO is meant to allow you to parallelize basically every step, import exactly the parts of the program you want at a given time in a quick and memory efficient way, etc.
- vvanders 10y ago
  Thanks for the clarification and detailed breakdown. Makes a lot of sense. Back when we'd use LTCG it was a ~30 minute link time penalty which prohibited it from all but the final release builds. Seeing this stuff move forward to be more effective to use is a great improvement.