Chrome - BBC Frontpage

To verify the findings of the previous use-case, we try to have a look at a different web-page. This time we load the BBC's mobile front-page. It's a fairly medium sized page with moderate complexity but which still represents a large amount of web content in mobile.
 

The little core data doesn't look much different than what we saw on the AnandTech frontpage. The little cores see a consistent high load, with a fairly large peak towards the main rendering phase of the page.

Chrome again seems to cause the system to spawn more threads than what the little cluster can accomodate.

The big cores also behave similarly to what we saw on the AnandTech front-page. There's a consistant load of a single large thread with some bursts where up to all 4 CPUs are doing some processing.

The total run-queue depths for the system again confirm what we saw in the previous scenario: Chrome is able to consistently make use of a large amount of threads, so that we see use of up to 6 CPUs with small bursts of up to almost 9 threads. 

What is interesting about the Chrome results is that most of the threads are placed on the little cores, meaning we have a large amount of small threads. Because the migration mechanisms of HMP don't migrate threads below a certain performance threshold, this causes some oversaturation of the little CPU cluster. 

This is an interesting implication for non-heterogeneous 8 core designs such as seen from MediaTek. In such a scenario having 8 little cores at more or less the same performance capacity would indeed make quite some sense. It's again MediaTek's X20 design with 2 clusters of 4 cores and a cluster of 2 high performance cores which comes to mind when looking at these results, as I can't help but think that this would be a use-case which would make perfect sense for that SoC.

Browser: Chrome - AnandTech Frontpage App: Hangouts Launch
Comments Locked

157 Comments

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