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
POST A COMMENT

157 Comments

View All Comments

  • nightbringer57 - Tuesday, September 1, 2015 - link

    Very interesting article, much more favourable to multi-core designs than I would have thought.

    Each article page must have cost an insane amount of time. However, I still feel like some more information could have been useful. This article is geared towards real-world use cases, but I think it would be interesting to repeat this analysis on a few commonly-used benchmarking apps. I feel like this would be interesting to compare them to real-world uses and may help understanding the results.
    Reply
  • ingwe - Tuesday, September 1, 2015 - link

    Yes that would be very interesting. I am always curious about how synthetics actually compare to more real world applications. Reply
  • Azethoth - Thursday, September 3, 2015 - link

    Every single synthetic I have ever seen vastly exaggerates the benefit. I would be interested in an actual real world use case that actually matches a synthetic. It would blow my mind if there are any. Reply
  • Andrei Frumusanu - Tuesday, September 1, 2015 - link

    I'll do a follow-up pipeline on this if the interest is high enough. Reply
  • bug77 - Tuesday, September 1, 2015 - link

    High enough +1.
    Please do the follow-up.
    Reply
  • tipoo - Tuesday, September 1, 2015 - link

    I'd definitely be interested. Reply
  • Drumsticks - Tuesday, September 1, 2015 - link

    Yes! This would be neat. Also, great article! Reply
  • ThisIsChrisKim - Tuesday, September 1, 2015 - link

    Yes, Would love a follow-up. Reply
  • HanakoIkezawa - Tuesday, September 1, 2015 - link

    I'm not sure of the practicality, but I would love to see a follow-up with Denver k1 and the A8X to see how lower core count out of order and in order SoCs are handled.

    This seriously was a fantastic article Andrei!
    Reply
  • kspirit - Tuesday, September 1, 2015 - link

    Yes please! +1 Reply

Log in

Don't have an account? Sign up now