3 ms·

> So on most real world applications, you shave perhaps a second or two off compilation and linking times. Which might be a significant part of the overall bui

by ithkuil 12y ago

> So on most real world applications, you shave perhaps a second or two off compilation and linking times. Which might be a significant part of the overall build time, if it takes 5-8 seconds to build.

jerf 12y ago
In my experience, it's not hard to have the same basic compile-run test-fix cycle with Go that it is with interpreted languages. Shaving a second off that may not save me a lot of literal clock time, but it makes it that much more pleasant to use, and therefore, that much less likely that I'll take unfortunate shortcuts. I haven't gotten up to a truly large Go code base, the whole shebang right now is only about ~25,000 lines, but the full save-test cycle is still comparable to what I get with a short Python script. (Though as I like to point out occasionally, if you sample a lot of languages in the world, real-world C and C++ programs have exceptionally long compile times due to ancient design decisions. Most other compiled languages are actually quite fast to compile. Go is striving to be fast even so, but when benchmarked against something other than C or C++ it seems less spectacular.)
- pcwalton 12y ago
  > (Though as I like to point out occasionally, if you sample a lot of languages in the world, real-world C and C++ programs have exceptionally long compile times due to ancient design decisions. Most other compiled languages are actually quite fast to compile. Go is striving to be fast even so, but when benchmarked against something other than C or C++ it seems less spectacular.) Nowadays, especially with unity builds, a lot of the reason that C and C++ are slow to compile (especially C) is actually that optimizations and codegen take a while. Most languages use JITs, so their compile steps are much faster. With the 6g/8g compilers, Go doesn't really do the same kind of optimization that e.g. GCC and LLVM do (e.g. SSA conversion, GVN, SCCP, LICM, aggressive algebraic simplifications, etc), so much of its build speed comes from that. In my experience, there's no free lunch: fast compiles come at the expense of runtime performance, and runtime performance comes at the expense of fast compilation.
- ithkuil 12y ago
  I guess that as soon as the Go compiler introduces more expensive optimization passes to the code the more it makes sense to ensure that these passes are run only once (i.e. when the source is compiled) and not many times (i.e. when the whole binary is "linked", which in the Go toolchain up to 1.2.x includes a translation from pseudo-instructions to actual instructions). TBH I don't know how much of the optimizations are currently doable before emitting pseudo-instructions, but I guess that moving the actual code generation in liblink makes sense nevertheless.

by ithkuil 12y ago

jerf 12y ago

In my experience, it's not hard to have the same basic compile-run test-fix cycle with Go that it is with interpreted languages. Shaving a second off that may not save me a lot of literal clock time, but it makes it that much more pleasant to use, and therefore, that much less likely that I'll take unfortunate shortcuts. I haven't gotten up to a truly large Go code base, the whole shebang right now is only about ~25,000 lines, but the full save-test cycle is still comparable to what I get with a short Python script. (Though as I like to point out occasionally, if you sample a lot of languages in the world, real-world C and C++ programs have exceptionally long compile times due to ancient design decisions. Most other compiled languages are actually quite fast to compile. Go is striving to be fast even so, but when benchmarked against something other than C or C++ it seems less spectacular.)

pcwalton 12y ago
> (Though as I like to point out occasionally, if you sample a lot of languages in the world, real-world C and C++ programs have exceptionally long compile times due to ancient design decisions. Most other compiled languages are actually quite fast to compile. Go is striving to be fast even so, but when benchmarked against something other than C or C++ it seems less spectacular.) Nowadays, especially with unity builds, a lot of the reason that C and C++ are slow to compile (especially C) is actually that optimizations and codegen take a while. Most languages use JITs, so their compile steps are much faster. With the 6g/8g compilers, Go doesn't really do the same kind of optimization that e.g. GCC and LLVM do (e.g. SSA conversion, GVN, SCCP, LICM, aggressive algebraic simplifications, etc), so much of its build speed comes from that. In my experience, there's no free lunch: fast compiles come at the expense of runtime performance, and runtime performance comes at the expense of fast compilation.
ithkuil 12y ago
I guess that as soon as the Go compiler introduces more expensive optimization passes to the code the more it makes sense to ensure that these passes are run only once (i.e. when the source is compiled) and not many times (i.e. when the whole binary is "linked", which in the Go toolchain up to 1.2.x includes a translation from pseudo-instructions to actual instructions). TBH I don't know how much of the optimizations are currently doable before emitting pseudo-instructions, but I guess that moving the actual code generation in liblink makes sense nevertheless.