SystemStats::getCpuSpeedInMegaherz() appears to return the current CPU clock frequency on Linux systems with clock frequency scaling (e.g., upboard). At idle, on the 1.44GHz UpBoard I’m evaluating getCpuSpeedInMegaherz() returns 479MHz.
Is this the intent of this function? I would have thought it could be used to indicate potential processing power for a given platform in order to scale things like polyphony. Giving a low-ball answer like this though doesn’t exactly meet that goal.
The Linux implementation of SystemStats::getCpuSpeedInMegaherz() returns the first ‘cpu MHz’ value from /proc/cpuinfo, which is apparently the current clock frequency of that CPU. A complete CPU frequency range can be assembled from various /sys files or by examining the output of lscpu (the latter looks a whole lot simpler)
by way of illustration:
model name : Intel® Atom™ x5-Z8350 CPU @ 1.44GHz
cpu MHz : 479.981
Model name: Intel® Atom™ x5-Z8350 CPU @ 1.44GHz
CPU MHz: 479.981
CPU max MHz: 1920.0000
CPU min MHz: 480.0000
Hmmmm the max MHz CPU doesn’t appear on every CPU type. Maybe JUCE should return the nominal CPU (the one after the @ symbol in the model name).
returning max might be problematic anyway, since I’m not sure whether that’s intended to be a sustainable clock rate, or only for short bursts. If this is meant to be used as a capability scaling for a given platform, the rated speed would make most sense.
But there’s no actual field for that, at least not reported by lscpu. In the example I posted, there is a rated frequency buried in the model string, but I’ve seen a system for which that’s not true: the ARM of a certain OMAP system. There might not be any machine readability requirements for the model string.
TBH nowadays there’s little point in even asking about CPU speed…
In olden times it was kind of meaningful but now that CPUs have dynamic speeds, asymmetric cores, etc, it really doesn’t tell you anything very useful. There’s a good argument for us just removing that functionality altogether.