Hacker News Reader

Comment by joenathan | Hacker News Reader

In overall power consumption how high is the CPU on the list of components? I'd imagine the display, WiFi, cell radios, Bluetooth are the real battery zappers. If a device was to be built using this big dog-little dog strategy, realistically how much battery life could expected to be gained?

View on HN

It's really tough to say. The short answer (I'm assuming you haven't done much embedded/mobile development) is that doing _anything_ uses power. Power is the Big Problem in mobile development. Use the CPU, it will burn up tons of power. If you are easy on it, but you are constantly streaming network data, the radios will burn up tons and tons of power. Even the GPS module uses a ton of power. Even the accelerometer measurably drains the battery when apps are accessing it. They say the reason the iPhone and some other smartphones still ship with such limited ram is that continually striping additional DRAM to keep the values fresh has too big of an impact on power consumption.

It's crazy, if you aren't used to thinking about it, how much your software's behavior can affect power usage. Have a sloppy inner loop where you spin on a lock, destroy the battery. Leave open HTTP connections that aren't really doing anything but are waiting on data, destroy the battery. Set the accelerometer update frequency hire than you absolutely need to, there goes the battery. Fire up a GL view that turns on the GPU, god forbid you try to run synchronously and spin on framebuffer renders, goodbye battery.

I have a theory, and it's...essentially totally baseless, hand-waving speculation, but I'll share it anyway, that that's really the difference you see with a lot of these new phones that come out that have terrible battery life. It's not necessarily that running the slightly larger screen automatically decimates the battery, say, its that the carriers don't have the discipline to be brutal with regard to the software's power consumption.

With iOS, this has historically been mitigated to some degree by the fact that 3rd party apps weren't allowed to run in the background, and that Apple was fairly psychotic about managing power use in its first party software. That is changing, but I suspect a lot of what has driven the API design there is sensitivity to power consumption.

It's actually wild, if you have an iPhone, say, to turn off the Wifi, 3G, and BT radios, and location services. Use it like a dumb phone. The battery will easily last for a week, probably a lot longer if its a new battery, and all you do is send texts and make the occasional call. The OS and phone radio can idle for a long time on a single charge, with occasional powerings of the screen. We think of phones as just being intrinsic power hogs due to the screen and phone functionality, but the power efficiency of those has risen dramatically over the last several years. It's all the other shit now, which is the shit that makes the phone interesting, that consumes all the power.

So yes, a dramatically more power-efficient CPU would make a huge difference. However, I am personally skeptical that having a separate, off-die CPU that's lower power consumption will lead to dramatically better power performance, but we'll see.

It really depends how much of each of those things you're using. If you have an LCD display that you set to be bright, its going to dominate your power usage when its on, but not if you're really maxing out the CPU. When you're not using the phone the cell radio is going to dominate power usage, but if you're on WiFi range it won't be that bad. Most of the time in that case the processor is going to be sleeping, but occasionally it will wake up and check for updates, etc, before going back to sleep. Its in a case like that where having it be a little A7 instead of the big A15 that wakes up will be a big advantage.

Careful though, that's apples to oranges. Clearly you're right: waking up a small core for a tiny task is going to require less power than doing the same on a big core. But the choice here is between a A15-only design (you need the big core always) and an A15+A7 design. The one with an A7 is a larger chip. That silicon area has built-in costs in both money and power consumption and has to be accounted for.

It certainly has an area cost, but its not going to contribute to power consumption when its not turned on. Power gating is a pretty well developed technique these days, and on the high Vt processes that everyone but NVidia uses you could probably make due with just clock gating for something as tiny as an A7.

If you have an Android phone it does have a breakdown. The couple times I've looked at mine it was screen and radios (wifi, cell) active/standby. But I think that is not important. As programmers, we look at the overall and can pick and choose parts to consider for optimization. Hardware isn't quite so general -- ARM needs to be ready in case a breakthrough in screen or radio battery usage leaves the CPU being the power hog.

I've noticed that when I play a game, I can drain the battery in a matter of 2-3 hours. My guess is that most of that power drain is due to the CPU and GPU. Certainly the screen is a big factor.

What would be amazing is if the OS on devices with these smaller cores would provide a mechanism for apps to request the kind of CPU they want. For example, services or background tasks could always run on the smaller core, even if they are fully utilizing the core, without getting pushed to the bigger core. This could help Android, for example, make sure that background tasks don't eat up battery life while the phone appears to be sleeping or doing other things.

It means you can have the CPU and OS running 24x7. So much simpler to program (and more like a desktop system) than most embedded where you have to wake up every N seconds, check for tasks and go back to sleep.

Reply on news.ycombinator.com