Various fixes for MacOS to make it behave similar to the Linux platform:
cpu will now return the actual CPU model name (e.g. Intel i7 / Apple M1 etc) and cpu_type will return the architecture (x86_64, arm64). I think the confusion started because of the cpu_type selected as the hash key to store architecture is very similar to the "CPU Type" Apple profiler entry which was the CPU model.
I don't think the actual computer model (MacBook Pro etc) should be returned in any "cpu" field. It would be fine for a "machine_model" field or something like that.
cpu_cores now returns the logical core count in the recommended way (hw.logicalcpu), to match the Linux behaviour. I added a physical_cores field which returns the physical count that was reported previously as cpu_cores. Similar functionality can be added to Linux.
POD clarifies behaviour and tests are added.
If some of the changes are not desired, I could take them out of this PR of course.
Various fixes for MacOS to make it behave similar to the Linux platform:
cpu
will now return the actual CPU model name (e.g. Intel i7 / Apple M1 etc) andcpu_type
will return the architecture (x86_64, arm64). I think the confusion started because of thecpu_type
selected as the hash key to store architecture is very similar to the "CPU Type" Apple profiler entry which was the CPU model. I don't think the actual computer model (MacBook Pro etc) should be returned in any "cpu" field. It would be fine for a "machine_model" field or something like that.cpu_cores
now returns the logical core count in the recommended way (hw.logicalcpu
), to match the Linux behaviour. I added aphysical_cores
field which returns the physical count that was reported previously ascpu_cores
. Similar functionality can be added to Linux.If some of the changes are not desired, I could take them out of this PR of course.