cmd/go: GOAMD64=local to compile for local machine

[Jorropo]

Rational:

I am using go install to deploy code to a cluster since the go compiler compiles really fast and this save me from having to manage building and distributing binaries.
It would be nice if I could also take advantage of the small performance gain of newer instructions sets available with GOAMD64, v2 and above however my cluster is made of heterogeneous machines and CPUs which not all support the latest features making it impossible or sub optimal to hardcode a level in my deploy script.

---

Proposal:

Add GOAMD64=local level to the toolchain, the toolchain will at compile-time find what would be the highest compatible micro-architecture level of the compiling host's CPU and compile the binary as usual using the equivalent microarchitecture level.
Thus running GOAMD64=local go build . (or other building command) on a compiling host that supports at most GOAMD64=v2 will produce an identical result as running GOAMD64=v2 go build ., same for all architecture levels on CPU that would support at most thoses respectively.

If a command of the toolchain that might be GOAMD64 dependent for results is invoked with GOAMD64=local while the toolchain is built with runtime.GOARCH != "amd64" the invocation fails. (go install, go build ... but not things like go env or go help)

I am not proposing that GOAMD64=local become defaults, just that it exists, by default the toolchain will continue to emit GOAMD64=v1 for GOARCH=amd64 binaries (even for go install as spuriously changing the micro architecture level invalidates different level build caches which would make a go build . shortly followed by go install . much slower).

[seankhliao]

Isn't this already somewhat the case?

The Go toolchain may also generate newer instructions, but guarded by dynamic checks to ensure they're only executed on capable processors. For example, with GOAMD64=v1, math/bits.OnesCount will still use the POPCNT instruction if CPUID reports that it's available. Otherwise, it falls back to a generic implementation.

[Jorropo]

@seankhliao this would happen at compile time allowing the compiler to omit the dynamic check, the thing you linked compiles to a runtime check:
https://godbolt.org/z/8az84vv6x (left side is GOAMD64=v1, right side is GOAMD64=v3)

Note: this already exists, however you have to precisely tell the compiler which level you are targeting, what I am asking for is a level that is whatever best the current host supports.

[Jorropo]

FWIW gcc and clang have the same feature with -march=native.

[ianlancetaylor]

CC @golang/runtime

[apparentlymart]

When I first read this I reached the same conclusion as @seankhliao that this behavior is already the default, but I think both of us misunderstood what you were proposing.

I think what's implied in your proposal is that you want "native" to mean "whatever architecture is available on the system where the compiler is running", because you assume that the computer where the program will eventually run will either be the same computer or will have an identical CPU. Is that right?

I think others typically build one binary and ship it to many different servers to run, and so the runtime detection is what they want. It sounds like you are instead planning to build and run the executables on the same computer, and so you're intending to ask the compiler to assume that's true and look for opportunities to optimize based on what it can learn about the CPU that's running the compiler.

[Jorropo]

@apparentlymart exact, I'll try adding "the compiler will ..." to the proposal hopping to make it clearer.

Maybe if I just described the proposal as GOAMD64=local go build do like clang -march=native it would have helped more.
(actually they are slightly different because the clang backend is more granular than v1, v2, v3, v4, here this limits to the microarchitecture compilation support already existing)

[ianlancetaylor]

Just a note that if we do this for GOAMD64 we should presumably also do it for the GO${GOARCH} environment variables.

[mvdan]

Given that GOAMD64 can really help in some cases like -race being ~15% faster with v3 (https://go-review.googlesource.com/c/go/+/444396), I'd like to make use of it in CI to run go test -race ./... as well. I had thought about using GOAMD64=v3, but that assumes a little too much about what CPU the shared CI machine is using. GOAMD64=native would be an easier alternative.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group