Performance regeression using go1.14rc1

[D1CED]

What version of Go are you using (go version)?

$ go version 1.14rc1 and 1.13.7

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env (anonymised)
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/--/.cache/go-build"
GOENV="/home/--/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/--/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/--/sdk/go1.13.7"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/--/sdk/go1.13.7/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build174863045=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Run the benchmarks recommended by https://github.com/golang/go/wiki/Benchmarks (some of them are out of date btw.). And specifically:

github.com/ethereum/go-ethereum/common/bitutil BenchmarkFastTest2KB

using v1.9.10.

What did you expect to see?

About the same performance or better when using go1.14rc1 compared to 1.13.7.

What did you see instead?

About 90% regression.

Let me clarify that I am not involved in the ethereum project at all. I did just run some benchmarks and this popped out. Still I did a little bit of investigation and this benchmark uses unsafe code.

The patch notes of 1.14 mention:

This release adds -d=checkptr as a compile-time option for adding instrumentation to check that Go code is following unsafe.Pointer safety rules dynamically. This option is enabled by default (except on Windows) with the -race or -msan flags, and can be disabled with -gcflags=all=-d=checkptr=0.

So I did use -gcflags=all=-d=checkptr=0 but with no effect. Trying to use -msan for comparision
did result in the error gcc: error: unrecognized argument to '-fsanitize=' option: 'memory' and I think this should be address instead. Using -race however worked fine but with expected severe slowdown with 1.14 and 1.13 about equal in absolute numbers.

[dr2chase]

Reproducible, I'm going to guess that you have the new Intel microcode which penalizes certain unaligned jumps severely.

Till we align those branches (I don't think for 1.14.0) this is a luck-of-the-draw problem -- sometimes 1.13 picks wrong, sometimes 1.14 picks wrong, sometimes neither, sometimes both. There's a CL for that from Intel ( https://go-review.googlesource.com/c/go/+/206837 ), another simpler version that I am trying to finish that only pads with nops.

[dr2chase]

Also, this is a duplicate of #37121, it just happens to be much more painful.

[D1CED]

Thanks for clarification.
Great to see you are working on this. Sad the see that the Go team has to go the extra mile and concerning themselves which Intels mistakes.

35881 also seems relevant here.

And finally @gopherbot please add label performance for reference.