Add OS.get_physical_processor_count() method

[Calinou]

This returns the number of physical CPU cores on the system, as opposed to OS.get_processor_count() which returns the number of logical CPU cores on the system.

Use cases:

• Configure parallelism for algorithms that don't scale well to logical CPU cores. In most cases, using the number of logical cores as a basis is recommended, but there are select cases where using a lower core count that matches the physical core count is more suited.
• Troubleshoot performance issues, as you can now detect whether a user has HyperThreading enabled or not (by checking whether OS.get_physical_processor_count() and OS.get_processor_count() are different).

Testing project: test_physical_cpu_count.zip

• This partially addresses Add methods to query CPU hardware properties (core topology, utilization, temperatures, core clocks) godot-proposals#6821.

TODO

• Fix Windows implementation.
• Test macOS implementation. I tested this on a M1 Mac mini and it returns 8 which sounds expected.

[bruvzg]

This probably won't work on BSD, so something sysctl based, similar to the macOS, probably should be added.

It seems to be kern.smp.cores for FreeBSD, not sure about other BSDs (maybe hw.ncpu).

[Calinou]

I've added code to support *BSD but I can't test it, since I currently don't have a VM setup active.

[Ivorforce]

sysctlbyname may error, returning != 0:

https://developer.apple.com/documentation/kernel/1387446-sysctlbyname#return_value

I don't know though if it actually does in any practical situation.

[darksylinc]

I feel the documentation should mention the result value should be cached because calling get_physical_processor_count() can potentially be expensive.

[bruvzg]

I feel the documentation should mention the result value should be cached because calling get_physical_processor_count() can potentially be expensive.

Any reasons not to cache it internally? Processor count should not change in runtime.

[darksylinc]

Any reasons not to cache it internally? Processor count should not change in runtime.

I was thinking the exact same thing as I wrote it. Only thing to watch out is race conditions when caching the first time.

It is possible for complex computers to have CPUs turned off (and maybe become mainstream in the future?), but if that's becomes a reality for the consumer, caching it externally or caching it internally won't matter (plus, a whole lot of other problems more than just this function).

So yeah, no reason we cannot cache it internally.

[hpvb]

For people using virtual machines it could be useful to get the actual current CPU count. But that's a bit of a niche case.

I'm not entirely convinced that this is entirely useful though, Godot has no way to provide any kind of thread affinity, so getting the physical core count really isn't information you can do much with. Just running your heavy process on half the number of cores doesn't really necessarily prevent sharing on smt logical cores.

I don't really care about the method, but if we are going to document it as being good for that we need a whole pile of other infrastructure to actually tell the OS that we want tasks split away from core siblings.