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

  • Hrobertgar - Tuesday, September 1, 2015 - link

    Your spikes on the video recording appear to be every ~4 secs of video, could the CPU spikes be app / memory related?
  • badchris - Tuesday, September 1, 2015 - link

    Thank you for this excited article.And one problem,how do we explain 2 big core Snapdragon 808 is more efficient than 4 big core Snapdragon 810?
  • Andrei Frumusanu - Tuesday, September 1, 2015 - link

    You cannot make comparisons between different SoCs even if they have the same CPU IP and the same manufacturing process. The S808 is different from the S810 which are again different from Nvidia's X1 even if all 3 have A57 cores on TSMC 20nm.
  • badchris - Tuesday, September 1, 2015 - link

    nvm,i should realize this comparison is not scientific.
  • metafor - Tuesday, September 1, 2015 - link

    The S808 and S810 should be fairly similar though. That's not to say you can say that the only difference is the CPU configuration but a similar study on what the behavior is like on a different SoC with fewer cores would be helpful.

    Threading isn't 100% free and neither is thread migration. It might be good to take a look at just what the S810 is doing over time compared to the S808 in terms of CPU activity.
  • Andrei Frumusanu - Tuesday, September 1, 2015 - link

    I have data on all of that... It's just in need of being published in an orderly fashion.
  • kpkp - Tuesday, September 1, 2015 - link

    There are quite few other differences beside the 2 cores, starting with the memory controller.
  • badchris - Tuesday, September 1, 2015 - link

    thx for your notice.there're something i forgot
  • npp - Tuesday, September 1, 2015 - link

    As an ex-Android developer I can remember that the SDK not only encourages, but sometimes straight out enforces extensive usage of threads. For example, around API level 14/15, making a network request in the main thread would throw an exception, which may seem obvious to experienced developers but wasn't enforced in earlier versions. This is a simple example, but having the API itself pushing towards multi-threaded coding has a positive effect on the way Android developers build their apps. I'm not sure then why Google's own browser would be surprising for its usage of high thread counts - even a very basic app would be very likely to spawn much more than 4 threads nowadays.
  • Arbie - Tuesday, September 1, 2015 - link

    "I was weary of creating this table..."

    That's not surprising, after all your work ;-).

    Terrific article BTW which is up to Anandtech's long-time standards. Seems like a mini master's thesis.

Log in

Don't have an account? Sign up now