x/sys/cpu: report core information and speed

[seebs]

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

$ go version
go version go1.11.4 linux/amd64

Does this issue reproduce with the latest release?

Yes.

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

N/A. all of them?

What did you do?

Tried to use existing packages to get information about CPU core count, clock speed, and so on. Among them, gopsutil, intel-go/cpuid, and klauspost/cpuid. They all do some of what would be desireable.

What did you expect to see?

A way to get CPU model name (if available), core counts, and ideally some kind of clock speed information.

What did you see instead?

A tangled mishmash of possibilities. I can't find anything at all on Linux that can give the CPU's officially-rated clock speed that isn't "get the brand string and parse it manually". On darwin/freebsd, gopsutil gets reasonable numbers by parsing sysctl output. On Linux, it uses something from /sys, but it gets the "max" CPU speed -- thus, for a 3.00GHz Xeon with a "max" speed of 4.00GHz, it reports 4000MHz. cpuid can accurately report on cores/threads (aka logical cores) for a single chip, but can't tell you how many chips the machine has. gopsutil can report the number of physical cores on a Mac (you would see a single CPU entry with 2 cores for a typical 2-core i5), but can't tell you about threads or logical cores. on Linux, the same machine would show 4 1-core CPUs, but if you used a map to check for unique core ID strings, you could infer that there were two distinct cores available.

This is the sort of thing where the go runtime probably already has decent insight into core count, for instance, and I think the proliferation of not-quite-working methods for getting this information is a problem. I briefly considered writing my own, but I think that would be a very bad idea. I guess I'm sort of half volunteering to implement a simple starting point for this for at least some targets, but I don't have access to a broad enough pool of targets to implement it competently for everything.

For benchmarking-type purposes, I think both logical and physical core counts (or threads/cores, depending on terminology) would be extremely valuable to developers. Clock speed(s) less so, but they can still be a handy reference point for looking at what hardware a given test was run against.

[bcmills]

CC @randall77 @martisch for the related internal/cpu.

[seebs]

Oh, I forgot about this. A further note: It turns out that you can derive speed information from some recentish Intel CPUs with cpuid leaf 0x15, although I'm told that's sometimes wrong. Intel's chips provide a parseable speed in their brand string nearly-always, and Intel officially documented this as of ~2012. I don't know about the current state of parsing such things for AMD, or ARM.

It seems like something where a perfectly-reliable answer is probably impossible, but a reasonably good guess is probably possible, and the proliferation of partial and/or incomplete solutions in the wild is probably not great for the ecosystem. Speed is hard. Core count, on the other hand, whatever runtime's using for guessing NumCPU is probably a good start?

[randall77]

internal/cpu is just CPU ABI feature detection. It doesn't handle #cpus, #cores, clock speed, or anything like that.