7 ms·

I wonder why people are so impressed by the compile times. Why it is fast, is obvious: 1. Do not use #include (especially in combination with C++ template inst

by beza1e1 15y ago

I wonder why people are so impressed by the compile times. Why it is fast, is obvious: 1. Do not use #include (especially in combination with C++ template instantiation) 2. Do not use a heavily optimizing compiler backend The first point is fixed in every other modern language as well, so it is only an advantage over C/C++. Go will become somewhat slower, because people want free lunch, so at some point i expect LLVM or GCC will be used as the official backend. Does anybody use TinyCC for his C programs?

gillianseed 15y ago
Well it's true that the Go compiler isn't comparable to GCC in terms of optimization but it's still quite new and is likely to improve quite a bit. As for Go supporting other compiler backends that's already happening with GccGo which is a Go frontend for GCC and yes it does generate much faster code than the official compiler (although it still lacks some key features last time I checked). I don't think we'll see GCC (or LLVM) as the official backend though, as they've stated that the reason they decided to do the whole compiler from scratch was that both gcc and llvm backends were considered too large and slow.
- enneff 15y ago
  > although [gccgo] lacks some key features last time I checked Not anymore. Gccgo is "Go 1 complete" and will be supported as part of Go 1. You can even use the "go" tool with gccgo.
  - gillianseed 15y ago
    Thanks for the info, that's very nice. I can see this opening up a workflow where you develop against the standard compiler and then use GccGo for better performing final builds.
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).

by beza1e1 15y ago

gillianseed 15y ago

Well it's true that the Go compiler isn't comparable to GCC in terms of optimization but it's still quite new and is likely to improve quite a bit. As for Go supporting other compiler backends that's already happening with GccGo which is a Go frontend for GCC and yes it does generate much faster code than the official compiler (although it still lacks some key features last time I checked). I don't think we'll see GCC (or LLVM) as the official backend though, as they've stated that the reason they decided to do the whole compiler from scratch was that both gcc and llvm backends were considered too large and slow.

enneff 15y ago
> although [gccgo] lacks some key features last time I checked Not anymore. Gccgo is "Go 1 complete" and will be supported as part of Go 1. You can even use the "go" tool with gccgo.
- gillianseed 15y ago
  Thanks for the info, that's very nice. I can see this opening up a workflow where you develop against the standard compiler and then use GccGo for better performing final builds.

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).