Understanding Mobile CPU throttling

I’ve been seeing some weird CPU performance weirdness while working on a new Android project, and after digging around a bit, realized that the perf issue wasn’t in my code at all; the CPU was being throttled by the hardware, automatically

You see, pretty much all modern mobile CPUs have a process known as frequency scaling.  That is, in order to conserve battery, most mobile hardware will reduce the amount of voltage supplied to the CPU depending on the workload that’s provided to it.  If there’s not lots of work being done, then the CPU pulls less voltage, draining your battery less, emitting less thermal heat, and also slowing down the performance of your chip.

This process is basically unavoidable—most smartphones and tablets are built to run very quickly for a short amount of time. Under stress, however, they need to tone themselves down to prevent melting whatever enclosure they happen to be in. From the OEM standpoint, there are good reasons to throttle CPU cycle count, but it's a delicate balance. Throttle too much, and users won't see the benefits of that fast hardware they paid for. Don't throttle aggressively enough, and heat and battery life will both suffer. Typically, the CPU will start out at its maximum rated speed and fall off as the phone gets warmer.

This process is generally controlled by the OEM driver, whom updates frequency based on CPU load. A process which is problematic for CPU bound games, as the simulation will often see unknown oscillations in your CPU frame time. Even worse if you’re using a the deltaTime since the last frame in some computational capacity (after getting 6 frames of 16.6ms, you’ll suddenly drop to 48ms / frame for no reason, which can cause havoc on physics simulations)

Sadly for developers, there’s no direct work around. The hardware is going to do what’s best to keep it from melting. If you need to optimize for this, you need to:

• Not let the CPU get too idle (when it’s idle, the clock cycle goes down)
• Not let the CPU get too busy (when it starts to get hot, the clock cycle also goes down)

It’s not rocket science, but finding the sweet spot in your simulation will ensure that you’re getting full potential out of your CPU on mobile devices.

Thankfully, deltaTime derivations of the CPU shouldn't affect your overall frame rate since the GPU will still be running @ 59.94Hz.

Which, I suppose is something, right?

~Main

You can find Colt McAnlis here: