Hacker News Reader

Comment by jbarham | Hacker News Reader

One thing I especially appreciate about Go that's a huge win over other statically compiled languages is how phenomenally fast the compiler is. E.g., I just re-built the current RC release on my 2.67 GHz i5, and the whole build, including the C bootstrap environment and 300k+ LOC in the standard library, took under 30 seconds.

Recompiling my projects of a couple of thousand lines is instantaneous. It really makes you re-think the classic edit-compile-edit cycle since the compile time is negligible.

View on HN

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?

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.

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

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.

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.

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.

Go libraries are statically linked and inlining works across libraries.

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.

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.

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.

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

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.

This is just marketing.

Any language with modules is equally fast, only languages the use the C #includes mechanism are slow, because each #include needs to be imported and processed each time it is seen.

Turbo Pascal, Modula and Ada compilers were already running circles around C compilers back in the day.

It's absurd to claim it's marketing since in this exact thread people state they care about this things and appreciate the feature, a feature that can be quantitatively tested.

Btw, The Plan 9 C compilers, which are also included with the Go distribution, also compile C as fast as the Go compiler compiles Go. Both compilers were written by Ken Thompson.

It is marketing, because it is sold as Go was the first language to have such fast implementations, which is not the case, but many refer to Go as if it was the first language having such a feature.

Nobody ever claimed Go was the first language with a fast compiler, it was simply claimed that it builds much faster than C++ and Java.

There are compilers faster than the Go compilers in terms of lines compiled per second. Even Python parses code faster than the Go compiler, however, Go builds large, real life projects, faster because it is the only implementation that scales linearly with the number of components, other scale O(n^2)

Turbo Pascal, Modula, and Ada, which you bring into discussion may have had fast compilers, but the build process was still O(n^2), not O(n).

Numbers please

A fast compile time is one of the stated goals, is it not? I ask because this seems like the kind of thing that's hard to do correctly unless it's explicitly stated as a design goal.

Yes, the projects at Google in C++ or Java took an absurd amount of time to compile, even with distributed compiler farms.

>how phenomenally fast the compiler is

This, more than anything else, is what's really got me interested in trying out Go when I have some time! I know it's not the most important thing in the world - my projects are generally such that compile times aren't a huge time suck - but it's still an exciting thought nevertheless.

Reply on news.ycombinator.com