Go 1.17 is released

[Michael Knyszek]

Hello gophers,

We just released Go 1.17

To find out what has changed in Go 1.17, read the release notes:
https://golang.org/doc/go1.17

You can download binary and source distributions from our download page:
https://golang.org/dl/

If you have Go installed already, an easy way to try go1.17
is by using the go command:
$ go get golang.org/dl/go1.17
$ go1.17 download

To compile from source using a Git clone, update to the release with
"git checkout go1.17" and build as usual.

Thanks to everyone who contributed to the release!

Cheers,
Michael and Dmitri for the Go Team

[ben...@gmail.com]

Thank you, Go team, for all your work on this! I (and I think many others!) love all these behind-the-scenes changes that make our lives better.

I went to look for that 5% performance boost in my GoAWK interpreter (due to the new register-based calling convention), and found a 38% improvement instead!

$ time goawk_go1.16 'BEGIN { for (i=0; i<100000000; i++) s += i; print(s) }'
4999999950000000
real    0m10.158s ...
$ time goawk_go1.17 'BEGIN { for (i=0; i<100000000; i++) s += i; print(s) }'
4999999950000000
real    0m6.268s ...

Overall for GoAWK I get an 18% speed increase on my micro-benchmarks between Go 1.16 and 1.17 (see https://github.com/benhoyt/goawk/commit/1f314f421273b3dc164ff4e5d41363f4ac4d160f) and I measured an 8% speed increase on my "slightly more real-world" benchmarks that also do I/O (https://github.com/benhoyt/goawk/blob/master/benchmark_awks.py).

After some pointers from people (see https://news.ycombinator.com/item?id=28203608) and some digging into the assembly, I found that many of the function-call heavy methods in interp/interp.go do a lot less stack manipulation (as expected) but are also 60-70% of the size of the versions compiled with Go 1.16. The overall binary is not 60-70% smaller, of course (it's "only" 7% smaller), but the fact that these hot-loop interpreter functions are so much smaller is a good indication they're doing a lot less -- as confirmed by the perf numbers.

I know that some people haven't gotten as much as 5% improvement, and a few things actually slowed down, but I just wanted to share a success story.

-Ben

[jfcg...@gmail.com]

Hi,

I benchmarked sorty v1.0.18 on an old laptop with Core i5-4210M CPU & Manjaro Linux, between Go 1.16.7 and 1.17 (o for optimization flags, in seconds):

            16    16o   17    17o

Sorting uint32
sort.Slice|17.25|16.03|14.95|14.00
   sorty-1| 6.63| 6.18| 6.48| 6.09
   sorty-2| 3.45| 3.21| 3.39| 3.16
   sorty-3| 2.91| 2.66| 2.86| 2.63
   sorty-4| 2.54| 2.30| 2.51| 2.27
sortyLsw-1|15.12|14.39|13.80|13.01
sortyLsw-2| 7.87| 7.52| 7.21| 6.77
sortyLsw-3| 6.63| 6.15| 6.02| 5.30
sortyLsw-4| 6.01| 5.38| 5.27| 4.58

Sorting float32
sort.Slice|17.70|17.17|15.36|14.44
   sorty-1| 7.45| 7.00| 7.35| 6.84
   sorty-2| 3.91| 3.66| 3.84| 3.58
   sorty-3| 3.09| 2.86| 3.08| 2.80
   sorty-4| 2.75| 2.54| 2.77| 2.50
sortyLsw-1|15.82|15.22|14.58|13.53
sortyLsw-2| 8.28| 8.01| 7.64| 7.14
sortyLsw-3| 7.01| 6.49| 6.26| 5.59
sortyLsw-4| 6.18| 5.67| 5.45| 4.81

Switching to register-based calling convention seems to have paid off quite well :) Is there any other big performance improvement in this release, or is it all because of registers?

Thank you all for the release!