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

157 Comments

View All Comments

  • nightbringer57 - Tuesday, September 1, 2015 - link

    There are several faces to this problem. The inherent issue with multi core designs is that it is not trivial to develop your application so it uses several cores efficiently. The potential gain in using multi core designs is that it can do the same job for less power than a single core design. The articles answers the question "can today's typical software environment use several cores efficiently?" with a pretty objective yes. It does not necessarily state that this is superior to more simple cores, it even states that it is not relevant for other environments.

    Your computer can handle an order of magnitude more computation needs, but don't forget it is using two orders of magnitude more power. The switch to dual core processors in the first place (in desktops) was motivated by the fact the industry hit a wall where they could not raise frequency anymore (heat and power consumption being an issue), where two, more efficient cores could increase performance significantly while still using less power.
    Of course, the sweet spot does vary depending on the targeted power as well as the environment you're working in.

    Do the android phones hit this sweet spot? maybe. But, at least, they are capable of hitting this sweet spot, for that power target and this given environment. That's what this article says.
    Reply
  • name99 - Tuesday, September 1, 2015 - link

    "Your computer can handle an order of magnitude more computation needs, but don't forget it is using two orders of magnitude more power."

    This is simply not true. Apple (and others) are shipping laptops running Broadwell at, what, 4.5W?
    IF there were massive value in adding smaller cores to the Broadwell package (eg it could drop the average power to 2.5W) wouldn't Intel do that? They could, eg, add 2 or 4 Silvermont cores and have their own big.LITTLE system. They could even automatically switch threads in the HW if they don't want the OS to be involved, they way they handle DVFS automatically on their newest cores.

    What I see when I read through these comments is a collection of people not very familiar with OS scheduling who are happy to interpret "OS can schedule multiple threads" as "app requires multiple cores to function well", and a much smaller collection of professionals who understand that the two have little relationship to each other for very short duration threads.
    There's also a whole lot of claims being made here about power savings on the basis of absolutely fsckall evidence --- Andrei shows absolutely no graphs of the power being used during these runs, and it is HYPOTHESIS, not fact, that running say four lightweight threads on four A53 cores would use less energy than aggregating those four threads on a single A57. Maybe it's true, maybe it isn't --- I don't see any reason to simply assert that it's true.
    Reply
  • nightbringer57 - Wednesday, September 2, 2015 - link

    Well, when Intel ships Broadwell processors at 4.5W, they do consume only a little bit less than an order of magnitude more than your average cortex-A53 cluster.
    Using big.LITTLE configurations requires a lot of precautions at the very beginning of the conception of both cores. You don't just take lower-end cores and add them to the SoC. Both the higher end and the lower end core must be conceived as being big.LITTLE compatible.

    And, however impressive those processors from Intel were, keep in mind that if they didn't put some lower power SKUs out, it's probably because they can't. To get into lower power figures, they are still forced to resort to Atom processors. And Atom branded processos today are... Overwhelmingly 4-cores models.

    Once again, I'm not pretending this article is the final proof that 8 core designs are a must. But it shows that, at least, typical use cases are able to use all cores. Not that this is efficient. But there is potential for efficiency.
    Reply
  • name99 - Wednesday, September 2, 2015 - link

    You need to be a little more careful with slinging around the term "order of magnitude".
    A 4 core A53 cluster running FP on all CPUs (Exynos 5433, 1300MHz) uses about 865mW. That's a factor of 5 from Broadwell's 4.5W, not a factor of ten.

    I'm no fan of much of Intel's work and behavior, but I don't think we are well served when we ignore details, when the details hold most of the interesting facts.
    Reply
  • prisonerX - Wednesday, September 2, 2015 - link

    All you're saying is that currently software needs better single thread performance. Duh!

    What everyone else is saying is that you can't get increased performance, nor better power usage, going forward with a single thread performance strategy. Physics has spoken!

    It's nothing to do with OS scheduling and everything to do with software architecture. Everything is moving towards increasing parallelism and that will continue.

    That's why mobile phones now have 8 cores and will have more because they are not weighed down by legacy architectures.
    Reply
  • Jaybus - Tuesday, September 1, 2015 - link

    It is worse than that on the development side. Yes, it is non-trivial to develop an app that uses multiple cores efficiently, but it is actually impossible to develop an app that uses multiple cores efficiently on all platforms. Maintaining many different versions optimized for particular platforms is just not plausible when there are so many different platforms. Reply
  • prisonerX - Tuesday, September 1, 2015 - link

    What are you basing that on? Your own bias?

    In reality your single Haswell core is going to be slower and use a lot more power in the process.
    Reply
  • lopri - Wednesday, September 2, 2015 - link

    Do people read?

    "I should start with a disclaimer that because the tools required for such an analysis rely heavily on the Linux kernel, that this analysis is constrained to the behaviour of Android devices and doesn't necessarily represent the behaviour of devices on other operating systems, in particular Apple's iOS. As such, any comparisons between such SoCs should be limited to purely to theoretical scenarios where a given CPU configuration would be running Android."

    The world does not revolve around Apple. This article has nothing whatsoever with Apple products. Furthermore, the article does neither claim nor imply that wider fat cores are better or worse than big.LITTLE.
    Reply
  • jjj - Tuesday, September 1, 2015 - link

    Yet to read the full article just looked at the more relevant graphs but i do wish you would have tested some heavier web pages (since AT and BBC are not that heavy), some SoCs with only small cores and look at power too. Would be very curious about power for a quad A53 vs octa A53 at same clocks. Testing GPGPU on the midrange SoCs that actually do that, would be interesting too.
    Really hope next year we get 2xA72(+some A53s) in 20$ SoCs for 150-200$ phones with very nice CPU perf. Anyway, will read the full article as soon as i find the free time.
    Reply
  • Pissedoffyouth - Tuesday, September 1, 2015 - link

    >Yet to read the full article just looked at the more relevant graphs but i do wish you would have tested some heavier web pages

    Daily mail UK comes to mind as the heaviest website ever
    Reply

Log in

Don't have an account? Sign up now