The power management on the M2 Max has some fun corner cases. It's actually faster for me to compile LLVM on a warm day than a cold one. On a cold day, the CPU slowly warms up, hits some thermal throttling, then slowly heats up more and eventually the fans come on. On a warm day, the CPU hits the throttling threshold, goes straight through it, hits the 'fans on' threshold, and then the fans keep the CPU cool enough to reduce the thermal throttling.
@david_chisnall @whitequark @hayley @casandro we've seen similar counterintuitive stuff where on certain devices when we deploy noise suppression models that are more computationally heavy, average time to process 10ms of audio can actually go *down* instead of up because the CPU becomes loaded enough to throttle up. Very mysterious initially if you don't know where to look.
@halcy @whitequark @hayley @casandro
We also hit something like this with CPU affinity work in FreeBSD. Adding CPU affinity in a 24-core build machine made builds take longer.
It turned out that, on modern systems, snopping a peer's L1 cache is really fast, so the cost of a process migrating between cores was very low. But each job was sitting in hot loops that heated up specific bits of the cores. Thermal throttling kicked in for the core (or core cluster) triggered by the hottest bit. Semi-random shuffling of jobs around heated the chip more evenly and made the thermal throttling kick in later. This was even more noticeable in the less parallisable parts of the workload because it also meant making each core idle in turn for a bit, which uniformly improved cooling.