Why aren't there any ARM SoC's with only 1 or 2 .LITTLE cores?

[wilds]

Such as 2 A57's and 1 A53

or 2 A72's and 1 A57

Remember Tegra 3? It was a 5 core CPU with its 'Shadow Core' being a low power, low frequency a9.

That 1 low frequency core could handle most background tasks thrown at it, but the rest of the Tegra 3 platform was lackluster at best. Such as single channel RAM and poor quadcore A9 performance.

I just can't see the point of having 4 little cores for background tasks when 1 large, low clocked core could provide a potentially smoother experience. It doesn't even have to be a 'little' core, just clocked at a low frequency with a low voltage.

I realize that Nvidia's Shadow Core did only a small portion of what current .LITTLE cores can do now, but does having 4 a53's really benefit the user experience vs just having 1 or 2?

There are large manufacturers that haven't bothered with .LITTLE and their platforms maintain great performance and power consumption vs the big.LITTLE contenders. Is it even worth using up precious die space for performance that may not be noticed or a bit of extra battery life?

I'm sure having 4 .LITTLE cores can have its own advantages, but I can't see their worth vs just using fewer larger cores with nearly the same power envelope.

 

[Idontcare]

All depends on the software, right? Including the OS. And the consumer's preferred priority of latency versus throughput.

Do the majority of consumers in target price-class XYZ prefer a snappier experience (near zero lag/latency) on initiating actions even if it means the consumer experiences longer waiting times for those actions to complete? Or is it vice versa?

The product's target (consumer in price-class xyz) and the preferences of that target should ultimately be driving the business decisions on whether or not to pursue the development of the product as well as in terms of setting priorities in the project management of the development of that product.

If you see a lacking of a specific product in the market, there are a number of plausible reasons for such an observation, but it rarely starts with "it doesn't exist because no one has ever thought of it before"...instead, the answer usually begins with "when most recently assessed in focus group studies canvassing the target demographic, the overwhelming feedback was that such a product would be critically lacking in being able to enable consumer experience priorities A, B, and C...so the project was not pursued"

Now I can't provide you with a specific answer as to why we don't see more single-core .LITTLE products, but my suspicion is that it doesn't meet the target demographic's needs as well as the current scope of .LITTLE products.

Could also be something as benign as the marketing groups within the business killed the projects because they didn't want to take on the mammoth challenge of convincing consumers a single-core in .LITTLE config is superior to the competition's 4-core .LITTLE products.

But I'd argue that is simply coming full circle, back to the consumer's preferred experience. Part of the buying experience is to purchase something you won't regret having purchased, or being left to feel like you were duped into purchasing a poorer product for more money. Which is why consumers would blithely pursue a higher 4-core .LITTLE product (at the behest of the salesperson at the kiosk) over a lesser core-count product.

Its an experience the consumer would prefer to avoid, be it at the cash register or in their hands while using software. Just my guess.

 

[lopri]

Even at their lowest performance states the big cores consume more power than LITTLE cores. And low standby power consumption is exceptionally important to the devices they target.

http://www.anandtech.com/show/8718/the-samsung-galaxy-note-4-exynos-review/2

Tegras are a special case, but what NV tries to achieve is similar. I suspect Tegra's implementation (4+1) is an easier way, so to speak, than load-balancing asymmetrical cores in typical big.LITTLE implementations.

Others have gone with custom routes, e.g. Qualcomm & Apple. There is no set rule as to what is the right way since all these cores share same instruction sets. (ARMv7 or ARMv8)

 

[lopri]

BTW single LITTLE cores are used in many many things. They just do not get much attention due to their ubiquity or antiquity. The example of the former would be things like microwaves, GPS, TVs, media players, and the latter would be things like older iPhones, Kindles, and iPods. They all rock what we now consider LITTLE core(s).

Oh and all the smart watches run on single LITTLE cores, afaik. (kind of lets you know how full-blown Android/iOS might perform on them)

In other words - they are used in many things in plain sight. We just do not see them on flagship smartphones any more for the reasons Idontcare explained succinctly above.

 

[Cerb]

Even at their lowest performance states the big cores consume more power than LITTLE cores. And low standby power consumption is exceptionally important to the devices they target.

That is exactly why it exists. If the big cores were more efficient at very low power, then we'd just have them only.

BTW single LITTLE cores are used in many many things. They just do not get much attention due to their ubiquity or antiquity. The example of the former would be things like microwaves, GPS, TVs, media players, and the latter would be things like older iPhones, Kindles, and iPods. They all rock what we now consider LITTLE core(s).

No, they don't. Only fairly new products can possibly have such cores.

As small as the cores are, I don't see any point, when marketing alone makes a good case for multiple cores, and the licensing of the core, assuming sales are good, will cost far more than the actual implementation and production. With a halfway decent GPU, an extra 3 A57s aught to be almost free, physically, and cheap in terms of R&D. A $40 computer comes with quad, today.

 

[wilds]

I forgot how tiny A7/A53 is. Currently ARM recommends pairing A72 with A53 for the best big.LITTLE experience. I am not convinced for the need for 4 little cores.

What about race to sleep? If these little cores are given heavy tasks, will they end up using more power than a low-clocked A72 or A57? Looking at the power consumption Lopri linked, it isn't unreasonable to think of a 1 or 2 core ~500 MHz A57 for LITTLE instead of 4 A53's. Even just 2 A53's should be near-overkill for what these cores need to do.

Nvidia's Shadow Core was 1 A9 clocked at ~500 MHz. That was still enough to power through blu-rays and other simple tasks while shutting down the higher clocked 4 cores. I don't see any reason why a 1 or 2 core A53 isn't enough for notifications and other light tasks that the bigger cores can ignore. It just seems like a waste of space.

The average consumer doesn't even know how many cores are in their phone or tablet, let alone the architecture of the CPU. I just can't see a good reason to use 4 little cores other than manufacturer e-peen.

Look how sane ARM's slides are for recommending big.LITTLE:

http://www.anandtech.com/show/6420/arms-cortex-a57-and-cortex-a53-the-first-64bit-armv8-cpu-cores

2+2 arrangement makes perfect sense to me. Even a 4 core A57 or A72 + 2 core A53 seems perfectly reasonable.

While A53/A7 are tiny cores, 2 of those together is slightly larger than 1 A9 core (if manufactured at 32nm). That's a pretty big chunk of space that isn't being utilized the way it should imo.

I guess I should have titles the post as: why are manufacturers putting 4 little cores into tablets in smartphones when they aren't necessarily all needed?

 

[Arachnotronic]

ARM is paid royalties per core AFAIK, so of course they want to push more cores.

 

[Andrei.]

4 little cores is still a perfectly valid use-case.

 

[PPB]

4 little cores are good. But then again I would like ARM to start fiddling with turbo features on their cores. My moto G LTE sometimes have some derp moments that I attribute to not having enough oomph for some bursty loads. Turbo features are ideal for those use cases.

 

[SirCanealot]

As usual, I see these arguments all the time and people don't seem to understand that they are not paying 'per core' for smartphone SOCs. If a company decided to charge you extra $ for increasing core count, then it may become an issue.

If a company decides to make a phone with 5,000 cores and are still selling it for a competitive price, then that's fine.

And remember a phone with 5,000 cores won't really use much more power than a phone with 4 cores as the cores will be fully power gated when not in use. My girlfriend mostly uses her Galaxy Tab S in power save mode as she is happy with the performance for her needs, so those 'extra' 4 cores aren't even burning any energy at all, but they are there if she ever decides she needs the power.

IMO A7/A53 is so small there's literally no need to put any less than 4. You may as well go for a quad cluster as this will mean you're making sure that for light tasks and background tasks you're not going to fire up the big cores unless you really need them. If you decide to have 2 A53s on your new SOC and you're doing several light tasks on your phone at the same time, you'll need to fire up the big cores to avoid the phone lagging. There's literally no need to put any less than 4 little cores when building a new SOC.

I would like to see more experimentation with a smaller amount of big cores for use with budget SOCs (rather than the current trend of clusters of A53s with different clock speeds)m but they are all viable strategies that we need to experiment with, otherwise we simply won't know what works best in practice.

 

[wilds]

I realize how insignificant these little A53's are in cost, size, and power consumption. They are about the same speed as an A9, so it isn't too slow either.

I never was thinking that .LITTLE is inefficient, but rather detrimental to a smooth experience (probably hard to notice in areas I bet though). I was talking about Nvidia's companion core in Tegra 3 because it did exactly what it was supposed to do without any real problems.

It's performance is similar to 1 A53 core at 500 MHz. If one .LITTLE core can handle blu-ray videos and notifications while shutting down all the larger cores, then why is 2 not enough? Race to sleep not being fast enough with only 2?

In power saving mode, some smartphones will just lock down their big cores' frequency to save power rather than switching over to the smaller, more efficient cores (because they don't have them).

Now I realize that they will deliver longer battery life, but will 4 A53's provide the same user experience vs low-clocked A57's? I feel like the latter will feel far faster while still providing decent battery life.

Several manufacturers have proven that class-leading battery life can be possible with only big cores on the SoC without the need for smaller ones.

So I still feel like 4 little cores can be overkill in certain scenarios, but I can definitely see why they choose 4; especially when it comes to battery life.

I guess I don't see battery life as the end-all metric for all smartphones and tablets. I prefer better, smoother performance as long as battery is good enough for at least a day.

That is one thing I really like about Android are all the unique SoC's running the platform. We all seem to have different priorities with gadgets.

I suppose having 1 or 2 .LITTLE cores instead of 4 means you won't be able to use them in power-saving mode without lots of lag; but that is OK with me who only wants .LITTLE to do trivial things when my screen is locked.

 

[Systems analyst]

Some comments on the above interesting dialogue:

The race-to-sleep argument applies to a single core, but does not apply to the big.little configuration of ARM cores. Lopri's graph above explains why.

The big-little configuration is offered by ARM for A15/A7, A57/A53, A72/A53. It makes sense for A15, A57, A72, but may not make sense for a highly customised design, where, conceivably, the big.little concept is incorporated in one core; in the latter case, race-to-sleep may be replaced by switching to an internal lower-power mode.

The big.little scheme is an example of the "coarse/fine" design principle, applied very widely in engineering design.

The trend to more cores is also an example of a very widely applied engineering principle, in which more and more elements are used in configuring a system. It is coming in server cores using ARM IP.

ARM explain in their presentations that they do not charge strictly per core in a SoC, but they instead receive a reduced royalty percentage for additional cores. SoCs of up to 100 ARM cores have been announced, for servers of course.

 

[Headfoot]

Its as simple as this: the cores are tiny, so its really not a big deal to have 4. If you have 4 Bigcores then you can map one to one and avoid having to write and design logic to condense 4 to 2. It minimizes complexity in an already complex system (big.little transition) And you get a shiny marketing bullet point of MOAR COARS for no real loss (maybe 7-8mm2 die space)

or reverse, making a 2 little core SoC would be extra work for no benefit compared to 4.

 

[knutinh]

Its as simple as this: the cores are tiny, so its really not a big deal to have 4. If you have 4 Bigcores then you can map one to one and avoid having to write and design logic to condense 4 to 2. It minimizes complexity in an already complex system (big.little transition) And you get a shiny marketing bullet point of MOAR COARS for no real loss (maybe 7-8mm2 die space)

or reverse, making a 2 little core SoC would be extra work for no benefit compared to 4.

Even if die area may be of little concern, won't power draw be an issue?

-k

 

[SirCanealot]

Even if die area may be of little concern, won't power draw be an issue?

-k

Do you mean do the extra cores draw power? No, they are fully power gated when not in use.

 

[Wall Street]

One of the issues that have to overcome is one of software. The system generally needs to see a fixed number of cores. I believe that nVidia's implementation basically lies to the system and tells it that four cores are always running. I believe that something like hyperthreading (to make the one core look like four to the system) or a very complex driver would be needed to make this work.

The concept behind the ARM implementation is that when the big cores are idled, each big core can map all of its running processes over to its corresponding little core. This mapping would only work if you have the same number of active cores in all power configurations.

 

[Systems analyst]

There is description and bench - marking of big.little systems on :
http://www.arm.com/products/processors/technologies/biglittleprocessing.php
under the 'resources' tab.

The following pdf :
big_LITTLE _technology _moves _towards _fully _heterogeneous_Global _Task _Scheduling
describes the three different ways of using big.little on page 4.
On pages 8 and 9, they show a comparison of power useage for A15s only, v.A15/A7 big.little.
On page 11 they show a chart for' Angry Birds' running on a big.little system, where the A7s are sufficient; all four A7s are used, at reduced frequencies, to save power.These examples clearly show how big.little saves energy, in comparison with the use of larger, more powerful A15 cores.

The pdf :
big.LITTLE Technology : The Future of Mobile
also shows a power comparison, between A15s only, and A7/A15 big.little, figure 8.
Figure 4 shows the Cluster migration and GTS models of big.little. Both of these involve modified kernels, which are available from Linaro, as stated on pages 5 and 12.
Once the hardware is available, software will follow, to make use of the efficient parallel processing made available.

 

[poofyhairguy]

We just do not see them on flagship smartphones

Nope, just cheap ones like the Moto G.