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

156 Comments

View All Comments

  • 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!
    Reply
  • 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.
    https://www.qualcomm.com/news/onq/2013/10/25/power...
    I'm not sure that can be done in big.LITTLE.
    Reply
  • 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
  • lilmoe - Tuesday, September 1, 2015 - link

    "if the interest is high enough"

    :/ Really?
    Reply

Log in

Don't have an account? Sign up now