4 ms·

Go 1.1 performance improvements, part 2

89 points by neeee 13y ago

djhworld 13y ago
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!
cwzwarich 13y ago
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?
- pcwalton 13y ago
  The vast majority of users use the Plan 9-derived compilers.
- gillianseed 13y ago
  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 13y ago
    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!)
- _ak 13y ago
  Everyone I know uses gc. The only reason why I once considered using gccgo was because gc isn't available on Solaris. Changed jobs in the end, though, so don't have to use Solaris anymore.
queensnake 13y ago
Call me a spoilsport, but it's still slower than Java http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=java&lang2=go&data=u32 http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... . That takes the bloom off the rose for me.
- booop 13y ago
  Give it some time. It took a long time for Java and the JVM to be considered 'fast'.
- gillianseed 13y ago
  True that it's slower, but the 'one core x86'-based benchmark comparison is the one it does worst in. And I doubt a one core x86 is hardly typical of what Go code will be running on. Here are the results on a x64 quad: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=java&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... Overall Go loses here aswell, but it does much better than in the comparison you linked, and like others have mentioned Go is still very young compared to Java. Also, glancing at the tests where Go does really bad against Java they seem to be tests which rely much on runtime functionality, and the Java runtime/VM has had a very long time (+10 years?) in which to improve to it's current state.
- deleted 13y ago
  [deleted]
- strmpnk 13y ago
  Some might consider looking at more than just the time dimension though... Much more memory and more verbose code. I find that this adds up in real systems as there is less to tune for optimal performance and less code to audit.
- lolcraft 13y ago
  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.
fiatmoney 13y ago
Does anyone know if Go will generate AVX instructions?

89 points by neeee 13y ago

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!

cwzwarich 13y ago

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?

pcwalton 13y ago
The vast majority of users use the Plan 9-derived compilers.
gillianseed 13y ago
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 13y ago
  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!)
_ak 13y ago
Everyone I know uses gc. The only reason why I once considered using gccgo was because gc isn't available on Solaris. Changed jobs in the end, though, so don't have to use Solaris anymore.

queensnake 13y ago

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

booop 13y ago
Give it some time. It took a long time for Java and the JVM to be considered 'fast'.
gillianseed 13y ago
True that it's slower, but the 'one core x86'-based benchmark comparison is the one it does worst in. And I doubt a one core x86 is hardly typical of what Go code will be running on. Here are the results on a x64 quad: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=java&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... Overall Go loses here aswell, but it does much better than in the comparison you linked, and like others have mentioned Go is still very young compared to Java. Also, glancing at the tests where Go does really bad against Java they seem to be tests which rely much on runtime functionality, and the Java runtime/VM has had a very long time (+10 years?) in which to improve to it's current state.
deleted 13y ago
[deleted]
strmpnk 13y ago
Some might consider looking at more than just the time dimension though... Much more memory and more verbose code. I find that this adds up in real systems as there is less to tune for optimal performance and less code to audit.
lolcraft 13y ago
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.

fiatmoney 13y ago

Does anyone know if Go will generate AVX instructions?