4 ms·

Not only that, but I have heard people say that for compute (code generation) bound tests that are single threaded GCCGO does better; however, if you run code w

Not only that, but I have heard people say that for compute (code generation) bound tests that are single threaded GCCGO does better; however, if you run code with many goroutines (which most Go programs have) the standard Go compiler is faster. As of 1.1 Go code generation is also drastic improved. I would love to see Go 1.0.3 vs Go 1.1 vs GCCGO tests with a wide sample of programs.

gillianseed 13y ago
There is a benchmark test which includes the 'computer language benchmarks game' (aka language shootout) programs in the Go source tree under go/test/bench/shootout Last time I checked GccGo won most of them hands down and even more so when you changed the optimization from -O2 to -O3 (on my machines atleast 'i5/i7' -O2 always lost to -O3 in these tests so I don't know why they defaulted to -O2 here). This was on 1.03 I think, I haven't checked on 1.1x as of yet and given that there's been improvements in the Go compiler the overall results may have changed considerably.
gillianseed 13y ago
Did some of the go benchmarks on the lunch-break, I used standard 'go build' for the go results, and "go build -compiler gccgo -gccgoflags '-O3 -march=native'" for the gccgo results. The compilers where : Go 1.1rc, GccGo version 4.8.0 20130502 (prerelease), on an Arch Linux 64-bit system, Core i5 binary-tree.go gccgo-4.8: 0m0.932s go-1.1rc1: 0m1.835s binary-tree-freelist.go gccgo-4.8: 0m0.165s go-1.1rc1: 0m0.307s chameneosredux.go gccgo-4.8: 0m10.163s go-1.1rc1: 0m5.620s fannkuch.go gccgo-4.8: 0m44.533s go-1.1rc1: 0m56.389s fannkuch-parallel.go gccgo-4.8: 0m26.525s go-1.1rc1: 0m27.855s fasta.go gccgo-4.8: 0m1.126s go-1.1rc1: 0m1.250s mandelbrot.go gccgo-4.8: 0m30.004s go-1.1rc1: 0m30.537s nbody.go gccgo-4.8: 0m11.423s go-1.1rc1: 0m12.620s pidigits.go gccgo-4.8: 0m7.333s go-1.1rc1: 0m2.321s spectral-norm.go gccgo-4.8: 0m12.259s go-1.1rc1: 0m13.389s spectral-norm-parallel.go gccgo-4.8: 0m3.142s go-1.1rc1: 0m6.695s threadring.go gccgo-4.8: 0m37.421s go-1.1rc1: 0m9.800s Overall I'd say Go did better as in the instances GccGo won (although more numerous) it was typically with a small margin while on those GccGo lost we had larger margins. Overall Go 1.1rc seems to have improved quite a bit from my previous test (1.0x) unless my memory betrays me. Note that these are far from all the 'computer language benchmarks game' tests, only those which I managed to get done during lunch break, and as such they may skew the results compared to a full benchmark comparison.
- igouy 13y ago
  Note, the programs in go/test/bench are not necessarily the same as the Go programs shown on the benchmarks game. Most to the point, the mandelbrot program shown on the benchmarks game is not the same -- someone contributed an improved program to the benchmarks game.
  - gillianseed 13y ago
    Good to know, as such it would be a more apt comparison to use the currently best Go versions from the benchmarks game as they better reflect where Go stands performance-wise (with the usual micro benchmark disclaimer).
    - igouy 13y ago
      And to be fair, that's what CoffeeDregs did originally.

gillianseed 13y ago

There is a benchmark test which includes the 'computer language benchmarks game' (aka language shootout) programs in the Go source tree under go/test/bench/shootout Last time I checked GccGo won most of them hands down and even more so when you changed the optimization from -O2 to -O3 (on my machines atleast 'i5/i7' -O2 always lost to -O3 in these tests so I don't know why they defaulted to -O2 here). This was on 1.03 I think, I haven't checked on 1.1x as of yet and given that there's been improvements in the Go compiler the overall results may have changed considerably.

gillianseed 13y ago

Did some of the go benchmarks on the lunch-break, I used standard 'go build' for the go results, and "go build -compiler gccgo -gccgoflags '-O3 -march=native'" for the gccgo results. The compilers where : Go 1.1rc, GccGo version 4.8.0 20130502 (prerelease), on an Arch Linux 64-bit system, Core i5 binary-tree.go gccgo-4.8: 0m0.932s go-1.1rc1: 0m1.835s binary-tree-freelist.go gccgo-4.8: 0m0.165s go-1.1rc1: 0m0.307s chameneosredux.go gccgo-4.8: 0m10.163s go-1.1rc1: 0m5.620s fannkuch.go gccgo-4.8: 0m44.533s go-1.1rc1: 0m56.389s fannkuch-parallel.go gccgo-4.8: 0m26.525s go-1.1rc1: 0m27.855s fasta.go gccgo-4.8: 0m1.126s go-1.1rc1: 0m1.250s mandelbrot.go gccgo-4.8: 0m30.004s go-1.1rc1: 0m30.537s nbody.go gccgo-4.8: 0m11.423s go-1.1rc1: 0m12.620s pidigits.go gccgo-4.8: 0m7.333s go-1.1rc1: 0m2.321s spectral-norm.go gccgo-4.8: 0m12.259s go-1.1rc1: 0m13.389s spectral-norm-parallel.go gccgo-4.8: 0m3.142s go-1.1rc1: 0m6.695s threadring.go gccgo-4.8: 0m37.421s go-1.1rc1: 0m9.800s Overall I'd say Go did better as in the instances GccGo won (although more numerous) it was typically with a small margin while on those GccGo lost we had larger margins. Overall Go 1.1rc seems to have improved quite a bit from my previous test (1.0x) unless my memory betrays me. Note that these are far from all the 'computer language benchmarks game' tests, only those which I managed to get done during lunch break, and as such they may skew the results compared to a full benchmark comparison.

igouy 13y ago
Note, the programs in go/test/bench are not necessarily the same as the Go programs shown on the benchmarks game. Most to the point, the mandelbrot program shown on the benchmarks game is not the same -- someone contributed an improved program to the benchmarks game.
- gillianseed 13y ago
  Good to know, as such it would be a more apt comparison to use the currently best Go versions from the benchmarks game as they better reflect where Go stands performance-wise (with the usual micro benchmark disclaimer).
  - igouy 13y ago
    And to be fair, that's what CoffeeDregs did originally.