testing: add CPU name to standard benchmark labels

[martisch]

Currently only goarch and goos are printed as bechmark labels.

This proposal suggests to add the CPU name after a cpu label to the labels printed once at the top of benchmark output.

This will only happen when internal/cpu is able to detect the cpu type and otherwise the cpu label will not be printed.

Example with prototype http://golang.org/cl/234977:

goos: darwin
goarch: amd64
pkg: strconv
cpu: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
BenchmarkAtof64Decimal-4        	24431032	        46.8 ns/op

Optionally disabled/enabled CPU features could be printed in addition:
features: aesni, avx, sse41 ...

This will help to understand, reproduce and document benchmark results better in context of different system configurations.

Some commit messages with benchmarks made by Go contributors already contain this information, but added manually:
https://go-review.googlesource.com/c/go/+/230737
https://go-review.googlesource.com/c/crypto/+/169037
https://go-review.googlesource.com/c/go/+/40693
https://go-review.googlesource.com/c/go/+/10367
https://go-review.googlesource.com/c/go/+/76470
https://go-review.googlesource.com/c/go/+/171736
https://go-review.googlesource.com/c/go/+/125316
https://go-review.googlesource.com/c/go/+/171731
https://go-review.googlesource.com/c/crypto/+/39693
....

Related Proposal: #28398

[mvdan]

Should we also print information about the memory and disk models/speeds? I imagine this will greatly depend on what the bottleneck for a benchmark is.

[martisch]

I would leave it at CPU information for now as this is a common factor for many microbenchmarks. For me this also identifies the system I was benchmarking on, which is helpful when examining logs of benchmarks later.

[mvdan]

I agree; I was thinking outloud more than anything. There could be many other factors at play too, such as what kernel version and if any special boot options were used (such as intel mitigations which could slow down syscalls).

[gopherbot]

Change https://golang.org/cl/234977 mentions this issue: testing: print CPU name for benchmarks

[martisch]

@mvdan agreed. This could potentially be expanded in the future with a flag for printing even more information (ram, caches, kernel, ...) but I would leave that to a future extra and separate proposal.

The same information could then be easily added to e.g. go env or other commands with information for bug reporting if considered helpful.

[martisch]

Having gathered benchmarks from multiple machines with different CPUs again lately for comparison and the reactions posted/emojis are all seem to be positive. Does anyone object to adding this for go1.16?

[rsc]

Seems OK. Do we know how to procure this information for a wide enough variety of architectures and operating systems?

[bradfitz]

Seems OK. Do we know how to procure this information for a wide enough variety of architectures and operating systems?

Linux: cat /proc/cpuinfo
mac: sysctl -n machdep.cpu.brand_string
Windows: wmic cpu get

[martisch]

On all operating systems for 386 and amd64 we can use the CPUID instruction (see http://golang.org/cl/234977) to get the CPU name.

Generally for linux on other architectures /proc/cpuinfo can be read.

For ARM on all operating systems another (more indirect) but not as universal approach can be to read the model and vendor IDs with CPU instructions and then map those to common architecture names for the most common CPUs (e.g. Cortex-A55, Cortex-A77 ...).

[ceseo]

For ppc64x, you have to rely on the OS. Currently, there is no exposed hardware CPU ID to userspace. On Linux, you can get that from /proc/cpuinfo or directly from the auxiliary vector (via the AT_PLATFORM variable — see LD_SHOW_AUXV=1)

[martisch]

@ceseo thanks for pointing this out.

I will work on to ammend my protoype patch for Linux on all CPU architectures to use AT_PLATFORM from the aux vector. We already use the same mechanism to get HWCAP bits from AT_HWCAP in the auxillary vector. It seems this could also work on BSDs.