4 ms·

Yeah, I guess I should've added 'So if it takes 3 mins to compile your code .. in the C# compiler' But either way, I'm glad you enjoyed it. > As someone who u

Yeah, I guess I should've added 'So if it takes 3 mins to compile your code .. in the C# compiler' But either way, I'm glad you enjoyed it. > As someone who used to spend a lot of time in C++ and LTCG I got a good laugh out of this(aside from the crashing part, ICE are always a bad thing). Our release link was ~40 minutes on each change. A long time ago I did some C++, so I know it can take longer, although I don't think I ever worked on something with 40 min build times!

vvanders 9y ago
Yeah, it was a great deep-dive. The 40 minute link times comes from Link Time Code Generation which can reduce your binary size pretty significantly(along with some code speed-ups)[1], without LTCG linking on the project was about 1 minute. Usually LTCG is a tool of last resort since the build times are so painful(and at the time was the only step that couldn't be parallelized). We were shipping on X360 with a hard memory limit and couldn't have a binary larger than 20mb if we wanted to hit them. If I recall correctly LTCG gave us back about 5-10mb which was a godsend in those times. [1] https://msdn.microsoft.com/en-us/library/bb985904.aspx https://msdn.microsoft.com/en-us/library/bb985904.aspx
- stochastic_monk 9y ago
  gcc, clang, and Intel all both support this feature, calling it "Link-Time Optimization".[1,2,3] This allows them to inline virtual functions they can resolve, non-inline functions which are not visible to external units, as well as perform combinatorial optimizations by being able to "see" more of the code together at once. In addition to binary size (which I've never worried about too much, as I mostly write code for scientific computing), it has often improved runtime significantly. The only other specific optimization besides -flto that I have had very real speedups from (not counting -O[23] or -Ofast) has been -funroll-loops. I use it on nearly every project. (And, to be honest, I haven't seen a big slowdown in compile time over just -O3, though I think a lot of my costs there are from templates.) [1] https://gcc.gnu.org/wiki/LinkTimeOptimization https://gcc.gnu.org/wiki/LinkTimeOptimization [2] https://llvm.org/docs/LinkTimeOptimization.html https://llvm.org/docs/LinkTimeOptimization.html [3] https://software.intel.com/en-us/node/522667 https://software.intel.com/en-us/node/522667
  - vvanders 9y ago
    Yup, pretty sure LTO and LTCG are pretty close these days, if not the same thing.
    - throwaway613834 9y ago
      Confused, was there ever a difference?
      - vvanders 9y ago
        LTCG is MSVC specific, given that they're different compilers I can't say if the optimizations were identical.
        throwaway613834 9y ago
        Oh, I thought you meant they used to be different features, not that they used to be different implementations of the same concept.
pjmlp 9y ago
Back in the early 2000, when I was doing a bit of C coding, even our C builds would take on average one hour per build configuration. So doing a full release build across all UNIX and Windows variants supported by our product would take almost a full working day.

vvanders 9y ago

Yeah, it was a great deep-dive. The 40 minute link times comes from Link Time Code Generation which can reduce your binary size pretty significantly(along with some code speed-ups)[1], without LTCG linking on the project was about 1 minute. Usually LTCG is a tool of last resort since the build times are so painful(and at the time was the only step that couldn't be parallelized). We were shipping on X360 with a hard memory limit and couldn't have a binary larger than 20mb if we wanted to hit them. If I recall correctly LTCG gave us back about 5-10mb which was a godsend in those times. [1] https://msdn.microsoft.com/en-us/library/bb985904.aspx https://msdn.microsoft.com/en-us/library/bb985904.aspx

stochastic_monk 9y ago
gcc, clang, and Intel all both support this feature, calling it "Link-Time Optimization".[1,2,3] This allows them to inline virtual functions they can resolve, non-inline functions which are not visible to external units, as well as perform combinatorial optimizations by being able to "see" more of the code together at once. In addition to binary size (which I've never worried about too much, as I mostly write code for scientific computing), it has often improved runtime significantly. The only other specific optimization besides -flto that I have had very real speedups from (not counting -O[23] or -Ofast) has been -funroll-loops. I use it on nearly every project. (And, to be honest, I haven't seen a big slowdown in compile time over just -O3, though I think a lot of my costs there are from templates.) [1] https://gcc.gnu.org/wiki/LinkTimeOptimization https://gcc.gnu.org/wiki/LinkTimeOptimization [2] https://llvm.org/docs/LinkTimeOptimization.html https://llvm.org/docs/LinkTimeOptimization.html [3] https://software.intel.com/en-us/node/522667 https://software.intel.com/en-us/node/522667
- vvanders 9y ago
  Yup, pretty sure LTO and LTCG are pretty close these days, if not the same thing.
  - throwaway613834 9y ago
    Confused, was there ever a difference?
    - vvanders 9y ago
      LTCG is MSVC specific, given that they're different compilers I can't say if the optimizations were identical.
      - throwaway613834 9y ago
        Oh, I thought you meant they used to be different features, not that they used to be different implementations of the same concept.

pjmlp 9y ago

Back in the early 2000, when I was doing a bit of C coding, even our C builds would take on average one hour per build configuration. So doing a full release build across all UNIX and Windows variants supported by our product would take almost a full working day.