Presented below, using a very unscientific method, are the results of comparing the go1 benchmark results for the two compilers.
Buried among that see of red are a few telltale signs that the more capable gcc backed optimiser can eek out better arithmetic performance.
I want to be clear that these are very preliminary results, and, like all all micro benchmarks are subject to interpretation.
I also want to stress that I am not dismissing gccgo based on these results. As I understand it gccgo lacks a few key features, such as escape analysis, which is probably responsible for most of the performance loss when the amount of computation is dwarfed by memory bookkeeping.
gccgo is developed largely by one person, ian Taylor, and is a significant achievement. Recently he and Chris Manghane have been working on decoupling the gofrontend code from gcc so it can be reused with other compiler backends, LLVM being the most obvious.
If you are interested in contributing to Go, please don’t forget about gccgo, or even llgo as possible outlets for your energies. Go itself is a stronger language because we have at least four implementations of the specification. This helps keep the compiler writers honest and avoids the language being defined by default by its most popular implementation.