[DannyBee]

"The A53 cores will likely carry the vast majority of every day use, and redouble the battery savings."

non-ARM-manufacturer citation needed :). My experience as a compiler guy (that makes the toolchains for these kinds of phones) has been that big little brings improvements to what these guys can shove on a chip and advertise, but so far not real improvements to battery life or real numbers.

There reason why is pretty simple.

In an ideal world, you don't want anything running at all. You don't want A53's "handling the majority of the workload". What you want is to wake up, do whatever work is needed as fast as possible, and go back to sleep. Period. Sleeping chips are lower power, by far, than idling chips.

If it's faster to do that work with an A57, it'll generally give you better battery life to do that. Again, this is right now, based on perf per watt/blah blah blah. Maybe someday, in the future, a53's will be so low power vs a57 that doing something else makes sense. But it's not true now, AFAIK.

Instead, they make big-little because they can't really increase the speed of the higher end cores more without increasing power usage too much.

[inversionOf]

You don't want A53's "handling the majority of the workload".

Yes. You do. If I'm casually browsing non-intensive web pages, e-reading, or watching a Netflix movie, or even encoding a video, the background is doing IO rate limited system updates and basic data logging, etc, the vast majority of the time the CPU demands are very low, but frequent enough that putting a CPU to sleep is completely out of the question.

An A53 has a much lower ceiling, but a much better middle tier power usage level, than the A57. Yes, if you want to run a benchmark the A53 is not a good bet (and is generally worse in a workload power usage), but it is a very good bet for most real world usage.

[DannyBee]

No, you don't.

Encoding a video should not be CPU, so let's get that out of there. Most of the rest is more GPU dependent than CPU dependent. The amount of CPU time you should be spending on these tasks is really low.

For example, web browsing and reading, the CPU should be asleep most of the time.

Now, don't get me wrong, there are plenty of very silly little tasks for A53's to do, but what you listed are not those tasks.

It's more things like "syncing" or something that is a poll loop and event bound, not something that is in any way CPU bound. Period. CPU bound stuff is not something for the A53's in this to tackle. It makes battery life worse. That is what the actual, in-the-field data says.

" a much better middle tier power usage level, than the A57"

Truthfully, for most A53 cores, this is true only in the dreams of the chip designers.

"but it is a very good bet for most real world usage."

Then what, pray tell, do you expect the A57's to be doing in this world?

And why, in practice, has big.little and other things not shown any better battery life at all if it's really a better way of doing things.

I have no doubt it may be a better way of doing things in the future, but it ain't right now ;)

[swetland]

CPUs enter and exit sleep on Android devices constantly. Back in 2007 on the MSM7201A we'd go to power-down sleep for any idle times of >50mS (nothing to schedule for the next 50mS). Run fast and go to sleep has always been the primary power policy.

That said there's plenty of lightweight threads and processes that are mostly IO or event bound, do very little compute, and will run in roughly the same time on a small core as a large core, but the small cores have a lower static power footprint (base cost to have them powered up at all), so big.little works out well there.

[inversionOf]

Run fast and go to sleep has always been the primary power policy.

A sleeping core is obviously the most efficient core, however you have said nothing to discount what I said. Putting a core to sleep is a very costly activity, which is exactly why it happens at the millisecond scale.

Before that happens, the core will likely have been frequency scaled to more appropriately fit the window's loading. I mean, we know this is the case right now, and that "run fast and go to sleep" is not the primary policy. It's "run as fast as appropriate for the workload to fill a quantum, and sleep when there is no workload". There are many if not most workloads that are externally bound, or event triggered enough that sleep is completely out of the question and running faster does nothing.

Your words have been used (out of context and inappropriately) to bolster DannyBee when they represent, literally, all that is wrong with Hacker News.

[ris]

"frequent enough that putting a CPU to sleep is completely out of the question"

Modern CPUs have many different levels of "going to sleep" and many of them can be switched in and out of very quickly.