The Mobile CPU Core-Count Debate: Analyzing The Real World
by Andrei Frumusanu on September 1, 2015 8:00 AM EST- Posted in
- Smartphones
- CPUs
- Mobile
- SoCs
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.
Facebook
Twitter
RSS
157 Comments
View All Comments
toyotabedzrock - Wednesday, September 2, 2015 - link
This article author is partly color blind, reading the hangout app launch section makes it obvious he can't see the color difference of 1800 and 2100.LiverpoolFC5903 - Wednesday, September 2, 2015 - link
Great piece from AT as usual. Very interesting to say the least.I remember reading another good piece about multiple core usage in Android in one of the android themed websites (Androidcentral?). It was a much simpler analysis and the premise was to debunk the myth that more cores are pointless at best and counter productive at worst.
The conclusion from the tests were unequivocal. Android DOES make use of multiple cores, both via multi threaded programs and discrete system tasks. So core count DOES matter, at least to an extent.
name99 - Wednesday, September 2, 2015 - link
No-one is denying that "Android can make use of multiple cores".What they are denying (for this article and similar) is that the core are
- a useful way to save power OR
- a way to make the phone feel/behave faster
This article, you will notice, does not answer either of those issues. It doesn't touch power, and there've been plenty of comments about above (by myself and others) why what is being shown here has no relevance to the issue of performance.
Do you really want to insist on claiming that articles prove what they manifestly do not, and insist on ignore the (well-explained) concerns of engineering-minded people about the sorts of tests that ARE necessary to answer these questions? Wouldn't you rather be on the side of the engineers trying to understand these issues properly, than on the side of the fanboys, uninterested in the truth as long as you can shout your tribal slogans?
darkich - Friday, September 4, 2015 - link
You make no sense.Ever heard of the benchmarks?
If all cores are used (which this article proves as a fact), and if the benchmark shows the chip scoring higher than the chip with less cores - then yes, more cores means better performance.
It is a matter of that simple logic.
And the whole massive myth that this analysis dispelled was exactly the following - more cores is an useless gimmick BECAUSE ANDROID APPS CANNOT make use of them
Hannibal80 - Wednesday, September 2, 2015 - link
Wonderful articleBillBear - Wednesday, September 2, 2015 - link
Absolutely fascinating stuff. I was seriously not expecting to see Mediatek's ultra high core count strategy vindicated by real world measurements. That's the great thing about taking measurements instead of just speculating.As a follow up, it would be fascinating to see how selectively disabling different number of cores effects timed tests.
For instance, select an extremely CPU heavy web site like Forbes and see if allowing half as many cores makes rendering the home page take twice as long.
serendip - Wednesday, September 2, 2015 - link
Excellent article as usual by Andrei. As an owner of a phone with the MT6592 Mediatek 8-core A7 chip, I was also skeptical about the point of having so many small cores. I only got the phone because it was cheap :) I've seen all 8 cores spike to max frequency when loading complex web pages or playing games. For common tasks, only 2 or 4 cores are used. I've also found that down clocking it doesn't slow things down much and yields longer battery life; modifying the single core upfreq and additional core activation thresholds could be key to optimizing these chips to one's usual workload.Notmyusualid - Friday, August 26, 2016 - link
Good comment - I've been pondering this all morning, hence why I'm back on this article. Looking at an A9 Pro right here, 4.4 configuration.It seems that the low cores have a min freq of 400MHz, which I find interesting, as they seem to sit a 691MHz most of the time. Two of the big four sit in sleep, with the other two at 833MHz.
I wonder how adjustment to the larger cores may improve battery life.
krumme - Thursday, September 3, 2015 - link
Absolutely brilliant article that moved my pre undertanding.zodiacfml - Thursday, September 3, 2015 - link
Anandtech does it again. You are my entertainment and knowledge at the same time.My thoughts: Quite not surprising after seeing some benchmarks of some SoCs in one or two years since. I think the question here is performance versus more cores. More but smaller cores are best for efficiency and probably better marketing. The only problem with these smaller cores is performance which is why we often see them on cheaper devices and doesn't feel as fast. We still need more frequency for some big things and I believe a fast dual core will answer that. So, I can't wait to see the X20.