Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/sys/cpu: report core information and speed #30239

seebs opened this issue Feb 14, 2019 · 3 comments

x/sys/cpu: report core information and speed #30239

seebs opened this issue Feb 14, 2019 · 3 comments
FeatureRequest NeedsDecision


Copy link

@seebs seebs commented Feb 14, 2019

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?


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.

@gopherbot gopherbot added this to the Unreleased milestone Feb 14, 2019
Copy link

@bcmills bcmills commented Feb 28, 2019

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

@bcmills bcmills added the NeedsDecision label Feb 28, 2019
Copy link
Contributor Author

@seebs seebs commented Feb 28, 2019

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?

Copy link

@randall77 randall77 commented Feb 28, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
FeatureRequest NeedsDecision
None yet

No branches or pull requests

4 participants