4 ms·

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 m

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 11y ago
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 ;)
- inversionOf 11y ago
  The amount of CPU time you should be spending on these tasks is really low. Which is exactly the point. They are not CPU intensive, but the CPU is constantly doing a multitude of little things, whether simply moving memory around from the GPU to storage, sending the render buffers for the 60fps display, etc. Another comment mentioned, rightly, that cores are put to sleep in they don't have anything to do in a quantum. A quantum is an enormously huge period of time, and is a macro power management technique, and is the last bastion behind idle frequency scaling, and big.little. Truthfully, for most A53 cores, this is true only in the dreams of the chip designers. You have zero expertise to be saying this. I mean, here's how Samsung actually does it on a big/little setup- http://www.androidauthority.com/galaxy-s6-octa-core-processor-usage-617585/ http://www.androidauthority.com/galaxy-s6-octa-core-processo... Here's Qualcomm- http://www.anandtech.com/show/8933/snapdragon-810-performance-preview/4 http://www.anandtech.com/show/8933/snapdragon-810-performanc... Here's ARM- https://www.arm.com/products/processors/technologies/biglittleprocessing.php https://www.arm.com/products/processors/technologies/biglitt... They favor the little cores, unless the process actually saturates the core at which point it is elevated to a big core, because the power profile for low demand tasks is far better for the small cores. I'm going to favor the industry's interpretation of this a bit more than your anecdotal, occasional compiler-writer knowledge. what do you expect the A57's to be doing in this world? ...
  - DannyBee 11y ago
    "You have zero expertise to be saying this." This is 100% false. I do bringup on these platforms. I know a lot about them. "I'm going to favor the industry's interpretation of this a bit more than your anecdotal, occasional compiler-writer knowledge. " Dude, i literally do the toolchain bringup on these platforms you claim i have no knowledge of. This is not "anecdotal occasional compiler-writer knowledge". This is "I get paid to make the stuff you keep talking about work fast and get good battery life out of it". If what you say was true, then one would expect that when they were brought up, they would have worse performance and better battery life. Instead, the exact opposite is true in most cases. They have slightly better performance, and much worse battery life. Try it sometime. Battery life is gotten back mainly through .. wait for it ... compiler optimization ... to speed up the software so things can sleep faster. Not to "move things onto the little cores to save power", as you seem to think. Since you want to attack my experience, remind me again, what background do you have in this again? (FWIW - I would stay away from this argument line as it is unlikely to serve you well) As swetland (who was android's main kernel guy for a long time) pointed out to you, you literally have no idea what you are talking about when it comes to CPU sleeping and what the main power policies are. BTW, much earlier i asked if you had anything other than self-serving industry press releases to back up your claims. I'm guessing the answer is "no", given what you've written. Anyway, i'm going to stop responding now, because i'm just some anecdotal compiler writer, and clearly i can't compete with your vast knowledge store and experience on this one.
    - inversionOf 11y ago
      This thread should embarrass you. Christ, I'm embarrassed for you. I linked multiple real world demonstrations (both the technical data, and actual observations of these cores in practice) of how big little is used for power consumption, including specific details of the core power profiles. You still allude to your great, clearly laughable, expertise and actually continue arguing this. Remarkable. You are a Hacker News "Expert" and a bore. You are far, far out of your depth, and you should stop responding to topics where your knowledge is hilariously wrong. you literally have no idea what you are talking about when it comes to CPU sleeping He said that cores slept as much as "every 50ms". 50ms is an enormous period of time, and is a colossally granular mechanism of power reduction. They didn't discount what I said at all (in fact, talking about the millisecond scale when discussing a costly CPU activity is pretty bizarre to begin with), though it is unsurprising that you try to hang on that. Not to mention that their comment is simply dated and wrong now regardless. anything other than self-serving industry press releases to back up your claims. Comical. And yet you'll wave your hand at "battery life" based upon utterly nothing. Hey guys - ARM, Samsung, Qualcomm --- disregard them, and disregard actual observations of how these SoCs operate in the field on varying demand workloads -- because this guy knows how compilers are written and he does little winky faces. Save the world from your ignorance. The mere fact that you continually reference your great compiler writer knowledge in relation to core design is, honestly, embarrassing.
swetland 11y ago
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.
- deleted 11y ago
  [deleted]
- inversionOf 11y ago
  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 11y ago
"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.

DannyBee 11y ago

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 ;)

inversionOf 11y ago
The amount of CPU time you should be spending on these tasks is really low. Which is exactly the point. They are not CPU intensive, but the CPU is constantly doing a multitude of little things, whether simply moving memory around from the GPU to storage, sending the render buffers for the 60fps display, etc. Another comment mentioned, rightly, that cores are put to sleep in they don't have anything to do in a quantum. A quantum is an enormously huge period of time, and is a macro power management technique, and is the last bastion behind idle frequency scaling, and big.little. Truthfully, for most A53 cores, this is true only in the dreams of the chip designers. You have zero expertise to be saying this. I mean, here's how Samsung actually does it on a big/little setup- http://www.androidauthority.com/galaxy-s6-octa-core-processor-usage-617585/ http://www.androidauthority.com/galaxy-s6-octa-core-processo... Here's Qualcomm- http://www.anandtech.com/show/8933/snapdragon-810-performance-preview/4 http://www.anandtech.com/show/8933/snapdragon-810-performanc... Here's ARM- https://www.arm.com/products/processors/technologies/biglittleprocessing.php https://www.arm.com/products/processors/technologies/biglitt... They favor the little cores, unless the process actually saturates the core at which point it is elevated to a big core, because the power profile for low demand tasks is far better for the small cores. I'm going to favor the industry's interpretation of this a bit more than your anecdotal, occasional compiler-writer knowledge. what do you expect the A57's to be doing in this world? ...
- DannyBee 11y ago
  "You have zero expertise to be saying this." This is 100% false. I do bringup on these platforms. I know a lot about them. "I'm going to favor the industry's interpretation of this a bit more than your anecdotal, occasional compiler-writer knowledge. " Dude, i literally do the toolchain bringup on these platforms you claim i have no knowledge of. This is not "anecdotal occasional compiler-writer knowledge". This is "I get paid to make the stuff you keep talking about work fast and get good battery life out of it". If what you say was true, then one would expect that when they were brought up, they would have worse performance and better battery life. Instead, the exact opposite is true in most cases. They have slightly better performance, and much worse battery life. Try it sometime. Battery life is gotten back mainly through .. wait for it ... compiler optimization ... to speed up the software so things can sleep faster. Not to "move things onto the little cores to save power", as you seem to think. Since you want to attack my experience, remind me again, what background do you have in this again? (FWIW - I would stay away from this argument line as it is unlikely to serve you well) As swetland (who was android's main kernel guy for a long time) pointed out to you, you literally have no idea what you are talking about when it comes to CPU sleeping and what the main power policies are. BTW, much earlier i asked if you had anything other than self-serving industry press releases to back up your claims. I'm guessing the answer is "no", given what you've written. Anyway, i'm going to stop responding now, because i'm just some anecdotal compiler writer, and clearly i can't compete with your vast knowledge store and experience on this one.
  - inversionOf 11y ago
    This thread should embarrass you. Christ, I'm embarrassed for you. I linked multiple real world demonstrations (both the technical data, and actual observations of these cores in practice) of how big little is used for power consumption, including specific details of the core power profiles. You still allude to your great, clearly laughable, expertise and actually continue arguing this. Remarkable. You are a Hacker News "Expert" and a bore. You are far, far out of your depth, and you should stop responding to topics where your knowledge is hilariously wrong. you literally have no idea what you are talking about when it comes to CPU sleeping He said that cores slept as much as "every 50ms". 50ms is an enormous period of time, and is a colossally granular mechanism of power reduction. They didn't discount what I said at all (in fact, talking about the millisecond scale when discussing a costly CPU activity is pretty bizarre to begin with), though it is unsurprising that you try to hang on that. Not to mention that their comment is simply dated and wrong now regardless. anything other than self-serving industry press releases to back up your claims. Comical. And yet you'll wave your hand at "battery life" based upon utterly nothing. Hey guys - ARM, Samsung, Qualcomm --- disregard them, and disregard actual observations of how these SoCs operate in the field on varying demand workloads -- because this guy knows how compilers are written and he does little winky faces. Save the world from your ignorance. The mere fact that you continually reference your great compiler writer knowledge in relation to core design is, honestly, embarrassing.

swetland 11y ago

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.

deleted 11y ago
[deleted]
inversionOf 11y ago
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 11y ago

"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.