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
Samus - Wednesday, September 2, 2015 - link
They are both clearly android fans and haven't ever given anything else a chance. The fact they ignore Apple has consistently had superior single threaded performance in their SOC's years and this has translated to better UX just goes to show that Android targeting multithreaded performance is a solution looking for a problem. There are so many underlying issues to address first, specifically making efficient use the Linux scheduler and perhaps setting a compatibility list for hardware instead of saying just make anything and we'll find a way to run on it no matter how crappy it runs.tuxRoller - Wednesday, September 2, 2015 - link
Apple had not consistently had better performance per core. That's fairly recent (since cyclone, iirc). There are myriad issues at play.In the end, the market is best served by an open option, like Android, and customers choosing what works best for them and letting the rest fade away.
name99 - Wednesday, September 2, 2015 - link
"Apple had not consistently had better performance per core. That's fairly recent (since cyclone, iirc). "Since Swift. That's iPhone 5, 5S, 6 (2012, 2013, 2014) and likely to be 6S and 2015 at least.
Even the late-stage pre-Apple cores were substantially above average (in part because of Apple's custom SoC). The 4S was above the competition at the time:
http://www.anandtech.com/show/4971/apple-iphone-4s...
Most people would consider "consistent enough" for "long enough" to make the statement reasonable.
lopri - Wednesday, September 2, 2015 - link
And it is not like Apple don't resort to moar-cores. When they run into walls, they also have no choice but to take whatever routes that are available. Listening to some of the zealous Apple fans, one would mistake that iPhones have been rocking on a single-core all these years.They have moved to dual-cores on the phones, and 3-cores on tablets. Moar-cores on iDevices are only a matter of time. Those specialized ASICs with fancy names apple give ("Motion Processor" for one) are also a concession made by Apple that there are cases where big cores are not always the best route to take when efficiency matters.
Buk Lau - Wednesday, September 2, 2015 - link
"They are both clearly android fans and haven't ever given anything else a chance."uhh my first smart device ever is a 2nd gen iPod touch...
So just because I proved you wrong, I have to be an Android fanboy? You said you tried all these Android phones "every week" and have "shit experiences." Again, you didn't bring up any names or so. What phones have you even tried? Who's being a fanboy here and can only provide claims without backing them up with facts?
I don't understand why you are arguing about this superior ST performance when it's irrelevant to this article. What this article simply proves is that Android does make use of extra threads and you get a benefit in power efficiency due to running MT thread, nothing about performance. In fact in most scenarios shown in the test most of the little cores are even saturated which means the workload isn't heavy at all.
"Apple has consistently had superior single threaded performance in their SOC's years and this has translated to better UX"
any evidence that leads to this conclusion? also like tuxRoller said Apple only have IPC advantages in recent years with Cyclone series.
"There are so many underlying issues to address first, specifically making efficient use the Linux scheduler and perhaps setting a compatibility list for hardware instead of saying just make anything and we'll find a way to run on it no matter how crappy it runs."
Where did you get the concept of make anything and find a way to work? All OEMs and SoC manufacturers optimize for Android just like how they optimize for Windows in desktop. Like I said before, SoC manufacturers have to provide driver update every time there's a HAL change in Android. How well they can do to optimize is up to themselves but the fact is that they do have to make their hardware compatible for Android
Kutark - Wednesday, September 2, 2015 - link
Did i suddenly log onto the pcgamer forums? The instant someone expresses any level of dismay or concern for an apple product, or says they have good experiences with android phones, it automatically means they're a nutswinging fanboy?Buk Lau - Wednesday, September 2, 2015 - link
You can argue whether Apple is intentional or not but the end result is that 4S users are getting more sluggish experiences with their 4S after updated to iOS 8tuxRoller - Wednesday, September 2, 2015 - link
Linux isn't great about niceness There's a few ways to fix this. One is to use cgroups ,(which Android uses). This works pretty well but I'd still subject, ultimately, to the scheduler. The other way is to run the rt kernel. That obeys priorities nicely (heh), but would be a bear to wrestle into Android and you'd lose some power efficiency. Also the rendering framework of Android may have some issues.darkich - Friday, September 4, 2015 - link
Im calling not only BS, but a truckload of it.Just so full of ignorance and prejudice that it's probably not worth a thorough reply..if you do want one though, let me know and you will be served.
brianpauler - Saturday, July 17, 2021 - link
This is a very valuable change of Reddit. If you are a regular user of Reddit, you probably know this Reddit video downloader: