Hacker News Reader

Comment by astrange | Hacker News Reader

As long as the phone is plugged in, it doesn't particularly need to power save. You can also set the thread priority higher.

View on HN

Doesn't mean it will run at its max speed. Thermals are a huge issue in phone CPUs, and that's even worse when you add the heat generated by charging the battery. Maybe it's always running at 2.5GHz when plugged in, I don't know, but it seems extremely likely that it'll try to use less power just to reduce heat output.

Indeed, but it will hit 2.5Ghz occasionally, or it wouldn't be worth designing the CPU to go that fast.

My guess is it's designed for fast interactive use, so as long as you do your work in bursts of 300ms or less, you will probably get full speed.

Beyond that, and you'll be power or thermally throttled.

You have absolutely nothing to base that guess on though? What if Apple made the CPU to usually peak at, say, 2GHz and only go up to 2.5 under very special circumstances? What if the author has a, say, iPhone Xs, and the Xs's CPU is limited to never exceed 2.3GHz while the same CPU in the Xs Max reaches 2.5GHz? Or any number of other factors which I couldn't even start guessing at because the CPUs in smartphones and the software and firmware which controls them is an extremely complicated matter which I'd bet neither of us has any first-hand experience with.

I have experience with production CPU governing in some Android devices.

It is more art than science - you want to get the best possible user experience while not using too much power and not exceeding thermal and power limits.

Typically, governors are written as linux kernel modules. They get to choose the clock speed of groups of cores, and which cores are enabled. Some are in trustzone applications or android userland apps though.

Some hardware has extra constraints. For example, the autofocus mechanism on one device I worked on used a lot of power, so while the autofocus was initializing, the CPU had to be scaled down to the slowest speed for a few milliseconds, and the radio transmit disabled. The code ends up a mess because you need to pipe that info from all the other device drivers with no proper interface. A large number of devices do similar shenanigans when the battery is <50% because the battery voltage drops at high loads, and if it's already quite low, then you'll trip a brownout detector and reboot the device.

Thermal constraints are the main one - typically represented as some exponential curves. Ie. you may be at 2.0Ghz for 100ms, 1.8Ghz for 1 second, 1.6Ghz for 5 seconds, 1.4 Ghz for 30 seconds, etc. Depending on the history of the currently running process, the governor would try to decide if it was best to go to 2.0Ghz because this was going to be a quick task, or to only start at 1.6Ghz because it was going to be a long running thing.

Hopefully thats some insight! Check out XDA forums where some devices have a community of people into modding governors for different use cases.

I guess the numbers, but the phone body can dissipate something like 1W, the chip can output 5W of heat when fully utilized at max clock, the difference accumulates until it shuts down to protect itself from melting. You need active cooling to run it at max clock, and I don't know if the firmware will let you even if the temp sensor says it's fine.

This comment makes me want a liquid cooled and overclocked ipad pro.

Reply on news.ycombinator.com