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


View All Comments

  • modulusshift - Tuesday, September 1, 2015 - link

    Heck yes. And of course I'm interested if anything like this is even remotely possible for Apple hardware, though likely it would require jailbreaks, at least. Reply
  • Andrei Frumusanu - Tuesday, September 1, 2015 - link

    Unfortunately basically none of the metrics measured here would be possible to extract from an iOS device. Reply
  • TylerGrunter - Tuesday, September 1, 2015 - link

    Add one more vote for the follow up with synthetics.
    I would also want to see how the multitasking compares with the Snapdragons as they use the different frequency and voltage planes per core instead of the big.LITTLE.
    But I guess that would be better to see with the SD 820, as the 810 uses big.LITTLE. Consider it a request for when it comes!
  • tuxRoller - Wednesday, September 2, 2015 - link

    Big.little can use multiple planes for either cluster. The issue is purely implementation, tmk. Reply
  • TylerGrunter - Wednesday, September 2, 2015 - link

    big.LITTLE can be use different planes for each cluster but same for all cores in each cluster, Qualcomm SoCs can use different planes for each core, that's the difference and it's a big one.
    I'm not sure that can be done in big.LITTLE.
  • tuxRoller - Friday, September 4, 2015 - link

    I remember that but that doesn't say that big.LITTLE can't keep each core on its own power plane just that the implementations haven't. Reply
  • soccerballtux - Tuesday, September 1, 2015 - link

    to balance everything out-- meh, that doesn't interest me. most of the time I'm concerned with battery life and every-day performance. Android isn't a huge gaming device so absolute performance doesn't interest me. Reply
  • porphyr - Tuesday, September 1, 2015 - link

    Please do! Reply
  • ppi - Tuesday, September 1, 2015 - link

    Go ahead. This is one of the most interesting performance digging on this site since the random-write speeds on SSDs. Reply
  • jospoortvliet - Friday, September 4, 2015 - link

    Yes, this was an awesome and interesting read. Reply

Log in

Don't have an account? Sign up now