S-Browser - AnandTech Article

We start off with some browser-based scenarios such as website loading and scrolling. Since our device is a Samsung one, this is a good opportunity to verify the differences between the stock browser and Chrome as we've in the past identified large performance discrepancies between the two applications.

To also give the readers an idea of the actions logged, I've also recorded recreations of the actions during logging. These are not the actual events represented in the data as I didn't want the recording to affect the CPU behaviour.

We start off by loading an article on AnandTech and quickly scrolling through it. It's mostly at the beginning of the events that we're seeing high computational load as the website is being loaded and rendered.

Starting off at a look of the little cluster behaviour:

The time period of the data is 11.3s, as represented in the x-axis of the power state distribution chart. During the rendering of the page there doesn't seem to be any particular high load on the little cores in terms of threads, as we only see about 1 little thread use up around 20% of the CPU's capacity. Still this causes the cluster to remain at around the 1000MHz mark and causes the little cores to mostly stay in their active power state. 

Once the website is loaded around the 6s mark, threads begin to migrate back to the little cores. Here we actually see them being used quite extensively as we see peaks of 70-80% usage. We actually have bursts where may seem like the total concurrent threads on the little cluster exceeds 4, but still nothing too dramatically overloaded.

Moving on to the big cluster:

On the big cluster, we see an inversion of the run-queue graph. Where the little cores didn't have many threads placed on them, we see large activity on the big cluster. The initial web site rendering is clearly done by the big cluster, and it looks like all 4 cores have working threads on them. Once the rendering is done and we're just scrolling through the page, the load on the big cluster is mostly limited to 1 large thread. 

What is interesting to see here is that even though it's mostly just 1 large thread that requires performance on the big cores, most of the other cores still have some sort of activity on them which causes them to not be able to fall back into their power-collapse state. As a result, we see them stay within the low-residency clock-gated state.

On the frequency side, the big cores scale up to 1300-1500 MHz while rendering the initial site and 1000-1200 while scrolling around the loaded page.

When looking at the total amount of threads on the system, we can see that the S-Browser makes good use of at least 4 CPU cores with some peaks of up to 5 threads. All in all, this is a scenario which doesn't necessarily makes use of 8 cores per-se, however the 4+4 setup of big.LITTLE SoCs does seem to be fully utilized for power management as the computational load shifts between the clusters depending on the needed performance.

Introduction & Methodology Browser: S-Browser - AnandTech Frontpage


View All Comments

  • TylerGrunter - Tuesday, September 1, 2015 - link

    In fact you are in the right place to ask that question, as one of the profets os the mantra was Anand Lal Shimpi himself:
    Quoting from the article:
    "two faster cores are still better for most uses than four cores running at lower frequencies"
    You can read the rest if you are interested, but that´s how much of the mantra started.
  • retrospooty - Tuesday, September 1, 2015 - link

    I wont hold that against Anand, he was lobbying toward a job at Apple ;)

    But seriously, it was 2 years ago. At that time ""two faster cores are still better for most uses than four cores running at lower frequencies" may well have been the case. Also, no matter how you slice it, an 8 core big.little is not a true 8 core CPU. It's really still 4 cores.
  • retrospooty - Tuesday, September 1, 2015 - link

    /edit. I do remember alot of people crying "you dont need 8 cores" but again, that was people misunderstanding ARM's big.little architecture made worse by marketing calling it "8" cores" in the first place. Reply
  • TylerGrunter - Tuesday, September 1, 2015 - link

    I agree with you, and he may not have been THAT wrong at the time. But with the current implementations of power gating and turbos most of what he said has been rendered false.
    AFAIK, big.LITTLE can be a true 8 core, it actually depends on the implementation.
  • lilmoe - Sunday, September 6, 2015 - link

    "Also, no matter how you slice it, an 8 core big.little is not a true 8 core CPU. It's really still 4 cores."

    An 8 core big.LITTLE chip running in HMP mode (like the Exynos 5422 onward) is in fact a "true" 8 core chip in which all 8 cores can be running at the same time. You're thinking core migration and cluster migration setups in which only 4 cores (or a combination of 4) can be running at the simultaneously.
  • lilmoe - Sunday, September 6, 2015 - link

    "can be running at the simultaneously."
    *corrected: can be running simultaneously.
  • osxandwindows - Friday, September 25, 2015 - link

    If i run all 8 cores at the same time, wood it affect battery life? Reply
  • mkozakewich - Wednesday, September 2, 2015 - link

    If the option is really four weak cores or two powerful cores, I think the two powerful ones would make a better system. If we could have two powerful cores AND four weak cores, that would be even better.

    So I think he was probably justified.
  • mkozakewich - Wednesday, September 2, 2015 - link

    Just everyone who's easily influenced, really. I heard it from pretty much everyone. Someone I was talking to apparently "knew someone who designed a Galaxy phone." He claimed they wanted to design it with two cores, or something, but the marketers wanted eight. Reply
  • StormyParis - Tuesday, September 1, 2015 - link

    Very interesting, thank you. Reply

Log in

Don't have an account? Sign up now