Go 1.7 toolchain Improvements

This is a creation in Article, where the information may have evolved or changed.

This was a progress report on the Go toolchain improvements during the 1.7 development cycle. All measurements were taken using a Thinkpad x220, Core i5-2520m, running Ubuntu 14.04 Linux.

Faster compilation

Since Go 1.5, when the compiler itself is translated from C to Go, compile times is slower than they used to be. Everyone knows it, nobody is happy about it, and we ' re working on fixing it.

A Huge amount of effort in the 1.7 cycle have gone into reducing the amount of memory and the wall time the compiler uses F or various benchmark jobs. The results so far is:

Compile time for full build relative to Go 1.4.3

Previously I reported the current 1.7 compiler is 2x slower than Go 1.4.3 for the Jujud test. After re-benchmarking everything for this post, the slowdown are closer to 2.2x. Jujud is the largest of the three benchmarks–512 packages, vs 304 and 102 packages Respectively–and shows the largest slow Down.

cmd/goThe result is a little misleading as the code being compiled changes with every release, vs the fixed codebases of T He other benchmarks.

Note:the benchmark scripts for Jujud, Kube-controller-manager, and Gogs is online. Please try them yourself and report your findings.

Improved linker performance

A significant part of the build time improvements observed above come from improvements to the linker. Relative to Go 1.6, the linker are now roughly 66% faster.

Link time relative to Go 1.4.3

Relative to Go 1.4.3, linking are 10% faster for any non trivial binary, and up to 30% faster for large binaries like Jujud . These figures is for ELF targets only, mach-o and PE targets has not improved as much.

This isn ' t just useful for building final binaries. A faster linker improves the edit/compile/test cycle as each test was itself a program this must be linked and run. Anecdotally the linker now uses a third less memory, which was valuable when linking large binaries.

Smaller binaries

With code generation and linker improvements, binaries produced by the tip compiler is substantially smaller than Go 1.6. This is a work with been spearheaded by David Crawshaw.

Binary size (bytes)

At here, with the exception of its own cmd/go tool, go 1.7 produces smaller binaries than go 1.4.3.

Code Generation Improvements

The big feature for the Go 1.7 cycle are the new SSA backend for 64bit Intel.

While isn't the focus of this post, it would is remiss not to include some information on performance improvements in COM Piled code (not just the compiler ' s code). Stressing of course that these be preliminary figures as there is still four months to go before the new backend becomes The default for AMD64.

Go 1 benchmarks, go 1.6 vs 683448a

These numbers match the figures reported by Keith Randall a few weeks ago, and is in line with he thesis in the SSA desi GN Doc.

I think it would is fairly easy-make the generated programs 20% smaller and 10% faster. -khr

These improvements is not just the work of the SSA backend. The standard library and garbage collector continue to see improvements, including a 20% improvement to the FMT Martin Möhrmann. These benefits flow to all the platforms that Go supports.

The sole regression above is caused by a current limitation in the Register Optimiser which manages to registerise one Les s variable in the Mandelbrot inner loop.

Looking ahead

According to the release schedule, approximately one month remains before the 1.7 change window closes and the dev cycle E Nters the bug fix phase. There is still lots's work to does, but the improvements so far would easily make Go 1.7 the best Go release to date.