Chrome - AnandTech Frontpage

Chrome is the de-facto browser application on a lot of Android devices. We again use it to load the AnandTech frontpage and to analyse the CPU's behaviour. 
Starting off with the little cores:

Off the bat we see quite a large difference in the power state distribution graphs. Chrome seems to place much higher load on the little cores compared to S-Browser. When looking at the run-queue chart we see that indeed all cores are almost at their full capacity for a large amount of time. 

What stands out though is a very large peak around the 4s mark. Here we see the little cores peak up to almost 7 threads, which is quite unexpected. This burst seems to overload the little cluster's capacity. The frequency also peaks to 1.3GHz at this point. The reason we don't see it go higher is probably that the threads are still big enough that they're picked up by the scheduler and migrated over to the big cluster at that point.

The big cores also see a fair amount of load. Similarly to the S-Browser we have 1 very large thread that puts a consistent load on 1 CPU. But curiously enough we also see some significant activity on up to 2 other big cores. Again, in terms of burst loads we see up to 3 big CPUs being used concurrently.

The total run-queue depths for the system looks very different for Chrome. We see a consistent use of 4-5 cores and a large burst of up to 8 threads. This is a very surprisng finding and impact on the way we perceive the core count usage of Chrome.

Browser: S-Browser - AnandTech Frontpage Browser: Chrome - BBC Frontpage
Comments Locked


View All Comments

  • nightbringer57 - Tuesday, September 1, 2015 - link

    There are several faces to this problem. The inherent issue with multi core designs is that it is not trivial to develop your application so it uses several cores efficiently. The potential gain in using multi core designs is that it can do the same job for less power than a single core design. The articles answers the question "can today's typical software environment use several cores efficiently?" with a pretty objective yes. It does not necessarily state that this is superior to more simple cores, it even states that it is not relevant for other environments.

    Your computer can handle an order of magnitude more computation needs, but don't forget it is using two orders of magnitude more power. The switch to dual core processors in the first place (in desktops) was motivated by the fact the industry hit a wall where they could not raise frequency anymore (heat and power consumption being an issue), where two, more efficient cores could increase performance significantly while still using less power.
    Of course, the sweet spot does vary depending on the targeted power as well as the environment you're working in.

    Do the android phones hit this sweet spot? maybe. But, at least, they are capable of hitting this sweet spot, for that power target and this given environment. That's what this article says.
  • name99 - Tuesday, September 1, 2015 - link

    "Your computer can handle an order of magnitude more computation needs, but don't forget it is using two orders of magnitude more power."

    This is simply not true. Apple (and others) are shipping laptops running Broadwell at, what, 4.5W?
    IF there were massive value in adding smaller cores to the Broadwell package (eg it could drop the average power to 2.5W) wouldn't Intel do that? They could, eg, add 2 or 4 Silvermont cores and have their own big.LITTLE system. They could even automatically switch threads in the HW if they don't want the OS to be involved, they way they handle DVFS automatically on their newest cores.

    What I see when I read through these comments is a collection of people not very familiar with OS scheduling who are happy to interpret "OS can schedule multiple threads" as "app requires multiple cores to function well", and a much smaller collection of professionals who understand that the two have little relationship to each other for very short duration threads.
    There's also a whole lot of claims being made here about power savings on the basis of absolutely fsckall evidence --- Andrei shows absolutely no graphs of the power being used during these runs, and it is HYPOTHESIS, not fact, that running say four lightweight threads on four A53 cores would use less energy than aggregating those four threads on a single A57. Maybe it's true, maybe it isn't --- I don't see any reason to simply assert that it's true.
  • nightbringer57 - Wednesday, September 2, 2015 - link

    Well, when Intel ships Broadwell processors at 4.5W, they do consume only a little bit less than an order of magnitude more than your average cortex-A53 cluster.
    Using big.LITTLE configurations requires a lot of precautions at the very beginning of the conception of both cores. You don't just take lower-end cores and add them to the SoC. Both the higher end and the lower end core must be conceived as being big.LITTLE compatible.

    And, however impressive those processors from Intel were, keep in mind that if they didn't put some lower power SKUs out, it's probably because they can't. To get into lower power figures, they are still forced to resort to Atom processors. And Atom branded processos today are... Overwhelmingly 4-cores models.

    Once again, I'm not pretending this article is the final proof that 8 core designs are a must. But it shows that, at least, typical use cases are able to use all cores. Not that this is efficient. But there is potential for efficiency.
  • name99 - Wednesday, September 2, 2015 - link

    You need to be a little more careful with slinging around the term "order of magnitude".
    A 4 core A53 cluster running FP on all CPUs (Exynos 5433, 1300MHz) uses about 865mW. That's a factor of 5 from Broadwell's 4.5W, not a factor of ten.

    I'm no fan of much of Intel's work and behavior, but I don't think we are well served when we ignore details, when the details hold most of the interesting facts.
  • prisonerX - Wednesday, September 2, 2015 - link

    All you're saying is that currently software needs better single thread performance. Duh!

    What everyone else is saying is that you can't get increased performance, nor better power usage, going forward with a single thread performance strategy. Physics has spoken!

    It's nothing to do with OS scheduling and everything to do with software architecture. Everything is moving towards increasing parallelism and that will continue.

    That's why mobile phones now have 8 cores and will have more because they are not weighed down by legacy architectures.
  • Jaybus - Tuesday, September 1, 2015 - link

    It is worse than that on the development side. Yes, it is non-trivial to develop an app that uses multiple cores efficiently, but it is actually impossible to develop an app that uses multiple cores efficiently on all platforms. Maintaining many different versions optimized for particular platforms is just not plausible when there are so many different platforms.
  • prisonerX - Tuesday, September 1, 2015 - link

    What are you basing that on? Your own bias?

    In reality your single Haswell core is going to be slower and use a lot more power in the process.
  • lopri - Wednesday, September 2, 2015 - link

    Do people read?

    "I should start with a disclaimer that because the tools required for such an analysis rely heavily on the Linux kernel, that this analysis is constrained to the behaviour of Android devices and doesn't necessarily represent the behaviour of devices on other operating systems, in particular Apple's iOS. As such, any comparisons between such SoCs should be limited to purely to theoretical scenarios where a given CPU configuration would be running Android."

    The world does not revolve around Apple. This article has nothing whatsoever with Apple products. Furthermore, the article does neither claim nor imply that wider fat cores are better or worse than big.LITTLE.
  • jjj - Tuesday, September 1, 2015 - link

    Yet to read the full article just looked at the more relevant graphs but i do wish you would have tested some heavier web pages (since AT and BBC are not that heavy), some SoCs with only small cores and look at power too. Would be very curious about power for a quad A53 vs octa A53 at same clocks. Testing GPGPU on the midrange SoCs that actually do that, would be interesting too.
    Really hope next year we get 2xA72(+some A53s) in 20$ SoCs for 150-200$ phones with very nice CPU perf. Anyway, will read the full article as soon as i find the free time.
  • Pissedoffyouth - Tuesday, September 1, 2015 - link

    >Yet to read the full article just looked at the more relevant graphs but i do wish you would have tested some heavier web pages

    Daily mail UK comes to mind as the heaviest website ever

Log in

Don't have an account? Sign up now