Add an API to allow getting the number of "performance" cores-only

[alex]

Feature or enhancement

Proposal:

Currently Python provides os.cpu_count() which returns the total number of physical CPU cores.

On macOS M-class machines (and probably other ARM hardware), there are actually two types of CPU cores: performance cores, and efficiency cores.

For many tasks where a user wants to do "1 task per core", it really only makes sense to do 1 task per performance core.

Therefore it'd be sensible to expose this number. On macOS it can be found with the hw.perflevel0.logicalcpu sysctl.

This could be done in one of two ways, a new function, e.g. os.performance_cpu_count(), or as a keyword-argument to os.cpu_count(performance_cores_only=True).

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

[nineteendo]

Most ideas need to be discussed on Discourse: https://discuss.python.org/c/ideas/6
But that doesn't mean they'll be accepted. So, lower your expectations.

[colesbury]

Recent Intel consumer processors (like Alder Lake) also have a hybrid architecture with performance (P-Cores) and efficiency cores (E-Cores).

I've also often wanted to scale tasks with "1 per core", such as with the Tools/ftscalingbench/ftscalingbench.py, but just knowing the number of performance cores is usually not enough. I also want to know:

• Physical cores (i.e, ignore simultaneous multithreading / "hyperthreading")
• NUMA nodes (i.e., CPU sockets)

[alex]

Encompassing all these use cases seems to suggest a more substantial degree of API design required.

…

On Tue, Nov 19, 2024 at 12:24 PM Sam Gross ***@***.***> wrote: Recent Intel consumer processors (like Alder Lake <https://en.wikipedia.org/wiki/Alder_Lake>) also have a hybrid architecture with performance (P-Cores) and efficiency cores (E-Cores). I've also often wanted to scale tasks with "1 per core", such as with the Tools/ftscalingbench/ftscalingbench.py <https://github.com/python/cpython/blob/main/Tools/ftscalingbench/ftscalingbench.py>, but just knowing the number of performance cores is usually not enough. I also want to know: - Physical cores (i.e, ignore simultaneous multithreading / "hyperthreading") - NUMA nodes (i.e., CPU sockets) — Reply to this email directly, view it on GitHub <#127017 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBDOEDPQ226DK7CRFVL2BNX4XAVCNFSM6AAAAABSCNERJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBWGMYTQMBQGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[terryjreedy]

Perhaps os.cpu_count(details=True), where the exact details structure depends on the cpu. This would allow for processors to come.

[alex]

IMO if it has a completely different return type, it should be a different function.

…

On Tue, Nov 19, 2024 at 5:01 PM Terry Jan Reedy ***@***.***> wrote: Perhaps os.cpu_count(details=True), where the exact details structure depends on the cpu. This would allow for processors to come. — Reply to this email directly, view it on GitHub <#127017 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBCWB4NYLC3NR3CZL3D2BOYMHAVCNFSM6AAAAABSCNERJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBWHA2DCNRRG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- All that is necessary for evil to succeed is for good people to do nothing.