Hacker News Reader

Comment by saagarjha | Hacker News Reader

Yes, that's mentioned in the parent comment. The problem is that at slower frequencies also keep the core powered up for longer, which is often bad for power consumption. For many mobile devices, it's often much better to ramp up the processor to 100% and get the work done quickly, then rush to idle as quickly as possible.

View on HN

This strategy is typically known as "race-to-sleep" or "race-to-idle". Just figured it was worth mentioning, as there's lots of additional information that can be found if you know what to search for.

I see what you’re saying but I believe there’s an issue at the silicon level where the gates literally use more power to do the same work at higher frequencies.

It's a well-known feature of CMOS gates that they consume almost all of their power at the moments of switching. AFAIK only recently has static leakage become substantial, necessitating power gating.

Higher frequencies require higher voltage though, and this will increase power consumption.

To add context: this is especially true for tasks that are likely to end in the device sleeping again. Two examples: user checking phone after hearing a notification sound or opening the laptop lid to check train departure time in the browser (then closing it again).

The faster the CPU deals with the task once the device is fully awake the shorter the time other power hungry parts of the system (like screen) need to be awake.

That's why slow phones, where the user needs to wait for their browser to finish loading the page will never be battery effective.

Has anyone actually measured this on a laptop?

My view is that this works for CPU heavy tasks, but not for low-frequency repeated background tasks like browser window drawing, where if you speed up your CPU you just burn energy to get a higher framerate, something you generally don't care about on powersave.

So optimally you'd want to clock up for "burst tasks" and keep freq low for "per-frame tasks". But I don't know of a scheduler that does that, or even how it could do it. But if you assume most of your battery loss will be to frame tasks, powersave makes sense.

These kinds of things do get used in laptops–the keyword you're looking for is "race to idle", as the processor quickly clocks up and then rushes back to a lower-frequency state or even goes back to sleep. On the mobile side, I do know that Apple did work a couple years back to scale up to maximum clock rate very quickly to handle user-interactive tasks: https://www.anandtech.com/show/13392/the-iphone-xs-xs-max-re.... Then they'd ramp it back down to save on battery life.

Yeah but are there actually stats that this saves power in daily use?

I am not a hardware engineer, so I don't have actual stats on me, unfortunately. But the reasoning behind it makes sense: https://mjg59.livejournal.com/88608.html. Given that everyone is doing it, I am sure that there is data that shows that; I just don't have it :P

Well you can take the battery size (and screen times you get from those). iPhone batteries are tiny compared to android. Like seriously tiny that my 10Wh Powerbank can charge it 5 times with some to spare (I only really get 4 due to losses but still).

So yes comparing iPhones to anything else highly suggests that the tuning Apple did pays off. That being said: I’m not aware of a useful comparison. I’m not even sure how you would design something like that, ie what would you like to keep constant?

With the modern web there is no "rush back to idle". Browsers will burn your CPU until you turn off your browser, which in most cases is only when you turn your computer off.

Assuming you are using a reasonable browser with a reasonable set of websites open, a browser should not really burn unbounded CPU in the background. Tabs that do are generally throttled, allowing the scheduler to burst their work and then have the processor go back to sleep.

Are we assuming no tracking and ads as well?

But yeah I agree, it should not. But it does.

Reply on news.ycombinator.com