As a companion to goarch and cpu, I think we should also include the value of Go environment variables like GOAMD64 - similar env vars include GOARM, GOMIPS64, etc. They are listed together in go help environment.
This matters just like cpu does: benchmark numbers will vary between CPUs, and some benchmarks might benefit significantly from GOAMD64=v3 compared to the default of GOAMD64=v1.
For the sake of reducing verbosity, we could only print these if they are set to a non-default value. GOAMD64=v1 wouldn't be printed, but GOAMD64=v3 would be.
Arguably there are lots of other factors that could contribute to higher or lower benchmark results, such as what kernel the sytem is running, which C toolchain was used to build cgo, what Go version is being used, etc. However, env vars like GOAMD64 feel much more in line with the goarch and cpu lines we already print, and they are a set of Go build options which directly affect performance.
The text was updated successfully, but these errors were encountered:
I think this makes sense, and should be straightforward to do. I also don't think it would be too verbose to always print them (for the relevant platforms; i.e. don't print "GOARM" for "GOARCH=amd64"). We just need to pick names for the keys. Maybe just "goamd64," "gomips," etc.?
go test -bench
has printed system information likegoos
,goarch
, andcpu
as part of benchmark results for some time now:go/src/testing/benchmark.go
Lines 265 to 272 in 59ab6f3
As a companion to
goarch
andcpu
, I think we should also include the value of Go environment variables likeGOAMD64
- similar env vars includeGOARM
,GOMIPS64
, etc. They are listed together ingo help environment
.This matters just like
cpu
does: benchmark numbers will vary between CPUs, and some benchmarks might benefit significantly fromGOAMD64=v3
compared to the default ofGOAMD64=v1
.For the sake of reducing verbosity, we could only print these if they are set to a non-default value.
GOAMD64=v1
wouldn't be printed, butGOAMD64=v3
would be.Arguably there are lots of other factors that could contribute to higher or lower benchmark results, such as what kernel the sytem is running, which C toolchain was used to build cgo, what Go version is being used, etc. However, env vars like
GOAMD64
feel much more in line with thegoarch
andcpu
lines we already print, and they are a set of Go build options which directly affect performance.The text was updated successfully, but these errors were encountered: