4 ms·

You are mistaken about #2, optimization pass is not very relevant in total build time, even for compilers that spend a relatively long time in the optimization

by 4ad 15y ago

You are mistaken about #2, optimization pass is not very relevant in total build time, even for compilers that spend a relatively long time in the optimization pass. Go build times are fast because 1) the grammar is not ambiguous to yacc yielding an O(n) parser that doesn't require maintaining a symbol table, 2) Dependency resolution is handled in an unique way, objects pull their dependencies so if A depends on B, C depends on A, and D depends on C and B, D doesn't need to look for B, since C contains A, B, and C. This doesn't seem like much, but it is, build times scale linearly with the number of objects instead of O(n^2). The gc suite doesn't produce code as tight as gcc, but almost no code in the world is CPU bound, everything is I/O bound.

kibwen 15y ago
Could you link to a resource that describes Go's dependency resolution scheme? Specifically, I'm curious if this means that all libraries are dynamically linked, and if so, if this inhibits Go's ability to inline function calls between libraries.
- luriel 15y ago
  Go libraries are statically linked and inlining works across libraries.
- vetinari 15y ago
  Dynamically linked libraries are actually a little problem in Go. Library is opened via dlopen()/LoadLibrary() and symbols needed are looked up by the Go code, not by system dynamic linker.
  - 4ad 15y ago
    That's not true at all. In the few cases where dynamic linking is involved, it works just as you'd expect it to be.
    - vetinari 15y ago
      Go does not use native dynamic linker. Please check package syscall, specifically src/pkg/syscall/dll_windows.go. You will see for yourself, how it is implemented.
0xABADC0DA 15y ago
I find gcc usually spends about 80% of the total compile time in optimization with -00 as a baseline (which despite being 'no optimization' actually does some optimizations). This is just C code. Optimization takes a massive proportion of compile time these days. This is something the Google Go designers didn't understand because they had been programming for decades using a mostly unoptimizing compiler (for plan 9).
- 4ad 15y ago
  You will find that even though GCC spends 80% in the optimizing stage (I won't bother to refute your claim), impact of this is negligible in the grand scheme of things. The build is slow is because it scales O(n^2) with the number of files, and because there are many more steps involved in building a product, not because the compiler is slow (although GCC is). Go is designed to handle dependencies between objects in such a way so that it scales O(n). The Solaris/OpenSolaris/illumos build builds with two compilers at the same time. The Sun/Oracle proprietary compiler that generates better code, and GCC. GCC generated binaries are not usually used, instead GCC is used a shadow compiler to catch potentially not portable statements. You will find that if you disable GCC and build with only one compiler, build time decreases by 2%, not 50% as you might have expected.

by 4ad 15y ago

kibwen 15y ago

Could you link to a resource that describes Go's dependency resolution scheme? Specifically, I'm curious if this means that all libraries are dynamically linked, and if so, if this inhibits Go's ability to inline function calls between libraries.

luriel 15y ago
Go libraries are statically linked and inlining works across libraries.
vetinari 15y ago
Dynamically linked libraries are actually a little problem in Go. Library is opened via dlopen()/LoadLibrary() and symbols needed are looked up by the Go code, not by system dynamic linker.
- 4ad 15y ago
  That's not true at all. In the few cases where dynamic linking is involved, it works just as you'd expect it to be.
  - vetinari 15y ago
    Go does not use native dynamic linker. Please check package syscall, specifically src/pkg/syscall/dll_windows.go. You will see for yourself, how it is implemented.

0xABADC0DA 15y ago

I find gcc usually spends about 80% of the total compile time in optimization with -00 as a baseline (which despite being 'no optimization' actually does some optimizations). This is just C code. Optimization takes a massive proportion of compile time these days. This is something the Google Go designers didn't understand because they had been programming for decades using a mostly unoptimizing compiler (for plan 9).

4ad 15y ago
You will find that even though GCC spends 80% in the optimizing stage (I won't bother to refute your claim), impact of this is negligible in the grand scheme of things. The build is slow is because it scales O(n^2) with the number of files, and because there are many more steps involved in building a product, not because the compiler is slow (although GCC is). Go is designed to handle dependencies between objects in such a way so that it scales O(n). The Solaris/OpenSolaris/illumos build builds with two compilers at the same time. The Sun/Oracle proprietary compiler that generates better code, and GCC. GCC generated binaries are not usually used, instead GCC is used a shadow compiler to catch potentially not portable statements. You will find that if you disable GCC and build with only one compiler, build time decreases by 2%, not 50% as you might have expected.