

Go 1.1 performance improvements, part 2 - neeee
http://dave.cheney.net/2013/05/25/go-11-performance-improvements-part-2

======
djhworld
It's nice to see someone actively measuring this stuff and talking about
regressions and gains in a concise manner.

Definitely looking forward to the final article in the series!

------
queensnake
Call me a spoilsport, but it's still slower than Java
[http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...](http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=java&lang2=go&data=u32)
. That takes the bloom off the rose for me.

~~~
lolcraft
You're comparing Sun's Java 7, a mature mainstream, enterprisey language which
has probably the compiler, virtual machine and GC most advanced in _all of
Computer Science's history_ , with a niche language that some Googlers hacked
together. It would be too naive to expect Go to perform better than Java 7.
_However..._

Notice that Go, compiled with the Plan 9 compilers, performs as well as Java
in 7 of 11 tests and uses as much as 1/15 of its memory. All in all, not that
bad.

~~~
smegel
Your also comparing a native compiled language with an interpreted language
(albeit with a very good JIT compiler). At some point of maturity, I would
expect the native language to edge out Java, and when you look at the
benchmarks that is generally what you see.

~~~
burntsushi
Except for Haskell, OCaml, Pascal and SBCL Lisp. Java is faster than all of
those (on the shootout micro benchmarks), and I'd say all of them are quite
mature.

From what I can tell, on the Language Shootout, only C, C++ and Fortran beat
Java.

N.B. I think I only looked at benchmarks for x64 quad core.

~~~
queensnake
OCaml is instructive, that's another compiled-but-GC'd language. Looking at
them they're about the same.

[http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...](http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=ocaml&lang2=go&data=u32)

------
cwzwarich
Do most people using Go in production use the Plan9-derived Go compilers or
GCC? Are there any realistic programs where the Plan9-derived compilers
generate better code?

~~~
gillianseed
I dare say that the Plan9-derived compilers are used predominantly on all
platforms they support.

As for code performance, GccGo atleast seems to have the upper hand in code
which doesn't rely much on the runtime functionality, but not by very much on
the (admittedly few) tests I've done compared to the Go 1.1 6g compiler.

That said, AFAIK GccGo doesn't yet have the improvements made to the Go
runtime in 1.1, so chances are it will beat the Go 1.1 6g compiler even in
runtime reliant code once those improvements make it into GccGo.

Even so, the official 'plan9-derived' compilers have been improving greatly
during their relatively short existance, and as they are the main target of
optimizations/improvement aswell as being 'Go specific' they will likely end
up generating faster code for Go in all scenarios.

I see GccGo mainly as a solution for platforms to which Go hasn't yet been
ported (or perhaps never will), and I think it will remain as such. The main
focus, and practically all the end usage will be on that of the official
compiler suite.

It will be interesting to see how much more performance they can squeeze out
of Go compiler optimization, GccGo has proven that there is more to be had.

I would also like to see profile guided optimization on the Go compilers, I've
had cpu intensive code where GCC has given me 10%-20% better performance on
PGO builds (this was not Go code, I don't know if GccGo supports PGO?).

~~~
pcwalton
Many of the optimizations in gccgo are going to be hard to port to a compiler
that doesn't use SSA form. Go has a very reasonable reason to not use an SSA-
based IR--compiler performance--but I think it'll be hard to perform the same
kinds of optimizations without regressing compile time performance. (If they
can do it, though, my hat is off to them!)

------
fiatmoney
Does anyone know if Go will generate AVX instructions?

