`pyperf system {tune,show}` on macOS

[maurycy]

With the advent of LLM tools (eg: Claude, Codex), small optimizations are a gateway drug to contributing to the ecosystem. Many people, myself included, use a MacBook as a daily driver. However, there are many mechanisms in these machines and macOS itself that might make posted numbers not really trustworthy, even with --rigorous. I'm thinking about thermal pressure / throttling, coalescing, P/E cores, different power sources, low/high power mode, memory pressure, virtualization, noisy daemons in the background, etc. Of course, there's also pyperformance. Perhaps there's real value in extending system {tune,show} to this platform.

My understanding is that there's no macOS API for CPU affinity, but we can still check stuff (eg: pmset), provide actionable advice. There's taskpolicy and pthread_set_qos_class_self_np. The model is per worker, not global.

Perhaps the real issue here is improving our harness on macOS.

[vstinner]

I don't have access to macOS, so I cannot investigate this issue.

Do you want to propose a pull request?

[cschanhniem]

The current _system.py is built entirely on Linux kernel interfaces: sysfs cpufreq, /proc/irq, /dev/cpu/N/msr, intel_pstate, irqbalance systemd service, etc. Adding macOS support means building a parallel set of operations using Darwin sysctl and IOKit interfaces.

Key macOS APIs for each operation:

• Power source: pmset -g batt or IOKit via IOPSCopyPowerSourcesInfo()
• Turbo Boost: sysctl with hw.optional.perf_energy_preference on Intel Macs; on Apple Silicon there is no user-visible turbo toggle
• CPU frequency: sysctl hw.cpufrequency (Intel) or hw.perflevel0.physicalcpu_max_freq (Apple Silicon)
• Thermal state: pmset -g therm reports thermal pressure level (a key source of variance on MacBooks)
• System load: sysctl vm.loadavg
• Process affinity: thread_policy_set() via the Darwin affinity API (TCP_POLICY) — no equivalent to isolcpus on macOS
• ASLR: No /proc/sys/kernel/randomize_va_space equivalent on macOS; ASLR is always on with no user toggle

The important non-portable differences:

1. No CPU governor control: macOS handles DVFS completely in firmware/XNU. You cannot lock a specific frequency like you can with performance governor on Linux.
2. No per-IRQ affinity: No /proc/irq interface on macOS.
3. ASLR always on: Cannot be disabled.
4. Apple Silicon specific: sysctl hw.perflevel0.physicalcpu_max_freq returns 0 on Intel Macs; sysctl hw.cpufrequency returns 0 on Apple Silicon — they are mutually exclusive.
5. Thermal pressure: pmset -g therm is the single most important macOS-specific metric. MacBooks throttle under sustained load regardless of power source.

For a v1 macOS implementation, the minimal set of operations that have Darwin equivalents: power supply, CPU frequency (read-only), thermal state, system load. Turbo Boost control (MSR writes) is Intel-only and requires the IntelPowerGadget framework or direct IOConnectCallScalarMethod to the X86PlatformPlugin.

Apple Silicon also has no user-serviceable turbo toggle — the firmware manages E-core/P-core scheduling transparently, which makes true deterministic benchmarking harder than on Linux.