First, a note: this is a tiny synthetic bench. It’s not intended to answer the question: is GCCGo a good compiler. It is intended to answer the question: as someone investigating Go, should I also investigate GCCGo?
While reading some announcements about the impending release of Go 1.1 , I noticed that GCC was implementing a Go frontend. Interesting. So the benefits of the Go language coupled with the GCC toolchain? Sounds good. The benefits of the Go language combing with GCC’s decades of x86 optimization? Sounds great.
So I grabbed GCCGo and built it. Instructions here: http://golang.org/doc/install/gccgo
/tmp/gccgo/configure --disable-multilib --enable-languages=c,c++,go
go build mandel.go gccgo -v -lpthread -B /tmp/gccgo-build/gcc/ -B /tmp/gccgo-build/lto-plugin/ \ -B /tmp/gccgo-build/x86_64-unknown-linux-gnu/libgo/ \ -I /tmp/gccgo-build/x86_64-unknown-linux-gnu/libgo/ \ -m64 -fgo-relative-import-path=_/home/me/apps/go/bin \ -o ./mandel.gccgo ./mandel.go -O3
Since I didn’t install GCCGo, I need to specify library paths and I wasn’t able to use the simple “go -compiler” syntax for gccgo.
So the two files:
4,532,110 mandel.gccgo - Compiled in 0.3s 1,877,120 mandel.golang - Compiled in 0.5s
As a HackerNewser noted , stripping the executables could be good. Stripped:
1,605,472 mandel.gccgo 1,308,840 mandel.golang
Note: the stripped GCCGo executables don’t actually work, so take the “stripped” value with a grain of salt for the moment. Bug here .
GCCGo produced an *unstripped* executable 2.5x as large as Go produced. Stripped, the executables were similar, but the GCCGo executable didn’t work. So far the Go compiler is winning.
Performance [on a tiny, synthetic, CPU bound, floating point math dominated program]:
time ./mandel.golang 16000 > /dev/null real 0m10.610s user 0m41.091s sys 0m0.068s time ./mandel.gccgo 16000 > /dev/null real 0m9.719s user 0m37.758s sys 0m0.064s
So GCCGo produces executables that are about 10% faster than does Go, but the executable is nearly 3x the size. I think I’ll stick with the Go compiler for now, especially since the tooling built into/around Go is very solid.
Additional notes from HN discussion :