Slashdot Mirror
big.LITTLE: ARM's Strategy For Efficient Computing
MojoKid writes "big.LITTLE is ARM's solution to a particularly nasty problem: smaller and smaller process nodes no longer deliver the kind of overall power consumption improvements they did years ago. Before 90nm technology, semiconductor firms could count on new chips being smaller, faster, and drawing less power at a given frequency. Eventually, that stopped being true. Tighter process geometries still pack more transistors per square millimeter, but the improvements to power consumption and maximum frequency have been falling with each smaller node. Rising defect densities have created a situation where — for the first time ever — 20nm wafers won't be cheaper than the 28nm processors they're supposed to replace. This is a critical problem for the mobile market, where low power consumption is absolutely vital. big.LITTLE is ARM's answer to this problem. The strategy requires manufacturers to implement two sets of cores — the Cortex-A7 and Cortex-A15 are the current match-up. The idea is for the little cores to handle the bulk of the device's work, with the big cores used for occasional heavy lifting. ARM's argument is that this approach is superior to dynamic voltage and frequency scaling (DVFS) because it's impossible for a single CPU architecture to retain a linear performance/power curve across its entire frequency range. This is the same argument Nvidia made when it built the Companion Core in Tegra 3."
This solution _might_ be more power efficient. But it can not be more die and space efficient. Looking at keeping die sizes down to place more other crap on the die's, a ginormous core complex does not really fit the bill. Besides, if you want to keep core context switch times low, you must keep all caches etc on the larger cores hot and that draws power. This solution probably fits when you start a game, so that you have an explicit trigger to switch to the larger cores. If you are talking on demand ultra low latency switches, then again, keeping those cores hot costs power.
An asymmetric SMP machine is nothing new. An on-demand asymmetric SMP machine is something different however.
I still maintain that single-threaded performance (with a properly implemented, non retarded OS) far outweighs multi-threaded performance, so making an effort to starve those larger cores and still maintain power budget is probably the best bet anyway. (Intel x86).
Advertising much?
Some marketdroid had a field day finding that name, sheesh...
I would have added "i" in front of it, personally. Everybody knows i-anything is teh kewl these days.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Powered-down circuits have no leakage. Also a "little" implementation has vastly lower leakage than a bigger core.
GPU caches are designed to maximize bandwidth.
CPU caches are designed to minimize latency.
These two goals are at odds with each other.
It is no surprise that there is a market for GPU's. I think the surprise was that 3dfx could offer much-better-than-using-the-cpu performance so cheaply.
"His name was James Damore."
Its like a hybrid vehicle, when you only need to go slow it runs on a small motor, when you need power the big engine kicks in but needs more juice.
Big/little is a lazy way out of the power problem... Because instead of investing in design and development and in fine grained power control in your processor, you make the design decision of, "Heck with this -- silicon is cheap!" and throw away a good chunk of silicon when the processor goes into a different power mode... You have no graceful scaling -- just a brute force throttle and a clunky interface for the Kernel.
So, not all ARM licensees have been convinced or seen the need to go to a big/little architecture because big/little has that big disadvantages of added complexity and wasted realestate (and cost) on the die. Unlike nVidea (Tegra) and Samsung (Exynos), Qualcomm has been able to thus far keep power under control in their Snapdragon designs without having to resort to a big/little and has thus been able to excel on the phone. So far, the Qualcomm strategy seems to be a winning one for phones in terms of both overall power savings and performance per miliwatt -- where on phones every extra hour of battery life is a cherished commodity. Such may not be true for tablets that can stand to have larger batteries and where performance at "some reasonable expectation" of battery life may be the more important.
patents & lawyers
Nothing, except that Intel's most power efficient chips are in the same ballpark as the A15 (the power-hungry, fast 'big' chip) and they currently have nothing comparable to the A7 (the power-efficient, slow 'LITTLE' chip). And in the power envelope of the A7, an x86 decoder is a significant fraction of your total power consumption.
One of the reasons why RISC had an advantage over CISC in the '80s was the large amount of die area (10-20% of the total die size) that the CISC chips had to use to deal with the extra complexity of decoding a complex non-orthogonal variable-length instruction set. This started to be eroded in the '90s for two reasons. The first was that chips got bigger, whereas decoders stayed the same size and so were proportionally smaller. The second was that CISC encodings were often denser, and so used less instruction cache, than RISC.
Intel doesn't have either of these advantages at the low-power end. The decoder is still a significant fraction of a low-power chip and, worse, it is a part that has to be powered all of the time. They also don't win on instruction density, because both x86 and Thumb-2 are approximately as dense.
MIPS might be able to do something similar. They've been somewhat unfocussed in the processor design area for the past decade, but this has meant that a lot of their licensees have produced chips with very different characteristics, so they may be able to license two of these and implement something similar quite easily. Their main problem is that no one cares about MIPS.
I am TheRaven on Soylent News
Royalties in many licenses allow an unlimited number of CPUs on the same chip. You pay the royalty per design per chip.
Consciousness is an illusion caused by an excess of self consciousness.
Citation needed. Anandtech benchmarked Clovertrail against Tegra-3, the least power efficient ARM core currently on the market. The Tegra-3 has a very power-hungry GPU (which is nice if you've got the batteries for it...) and a fairly standard Cortex A9 core, which has lower performance-per-Watt than either the A7 or A15 and lower performance in absolute terms than the A15. Their latest Atom SoCs are in the same ballpark as the A15 in both power consumption and performance, but they're nowhere near the A7 in terms of power consumption, which uses less power under load than Clovertrail uses idle.
I am TheRaven on Soylent News
Rising defect densities have created a situation where — for the first time ever — 20nm wafers won't be cheaper than the 28nm processors they're supposed to replace.
The economic part is often left out on tech sites discussions, but it matters a lot. Up to now we had a sustainable situation where the cost of new processes increased regularly, but at the same time eventually the cost of the new process was lower. This allowed to get all on board and to also increase the reachable market, to get more revenues. That's why we have small micro-controllers everywhere nowadays.
Now when the cost of new processes increases, only the part of the market that trully need the improved density and performance will move on. And that's only a small part of the whole market. So we will have increasing costs, with a reducing addressable market. Double whammy. Expect end prices for high performance to rise quickly. That may slow down things significantly.
We'll see how it develops soon, but I would expect the economic to bite before we reach tech limits.
The cost of a 45 nm wafer was higher than that of a 65 nm wafer, etc. It was only the cost of an individual die that went down, because with a smaller geometry an equivalent die was smaller, thus there were more of them per wafer.
Covertrail is last gen tech. Its an iteration of the old atom. All intel CPUs up to "Haswell" were never designed from the ground up with power management in mind. It's all been bolt-on tech. These are Intels words.
Baytrail/silvermont;, coming out Q3 this year, will effectively erase any power advantage an Arm SoC. 22nm, designed from the ground up for power savings. 64bit. Quad core. Cheap. Intel fully expects to see sub 200 dollar windows 8 (Not windows RT) tablets.
So, you're comparing an unreleased product that doesn't yet exist to shipping products and accusing me of spreading BS? And repeating claims that Intel has made about its last three generations of Atoms, which have never yet been true? Okay then, enjoy your bubble.
Oh, this made me laugh:
All intel CPUs up to "Haswell" were never designed from the ground up with power management in mind
The Pentium 4 was the last Intel chip not to be designed from the ground up with power management in mind, at least according to the chief architect of the P4 project when I spoke to him a little while ago.
I am TheRaven on Soylent News
are you making fun of my product LITTLE.biggusdickus?
There is no right to feel safe thru security vaudeville at the expense of everyone's freedom, privacy and tax money.
Came here for a companion cube analogy, leaving disappointed :(
Big/little is a lazy way out of the power problem... Because instead of investing in design and development and in fine grained power control in your processor, you make the design decision of, "Heck with this -- silicon is cheap!" and throw away a good chunk of silicon when the processor goes into a different power mode... You have no graceful scaling -- just a brute force throttle and a clunky interface for the Kernel. So, not all ARM licensees have been convinced or seen the need to go to a big/little architecture because big/little has that big disadvantages of added complexity and wasted realestate (and cost) on the die. Unlike nVidea (Tegra) and Samsung (Exynos), Qualcomm has been able to thus far keep power under control in their Snapdragon designs without having to resort to a big/little and has thus been able to excel on the phone. So far, the Qualcomm strategy seems to be a winning one for phones in terms of both overall power savings and performance per miliwatt -- where on phones every extra hour of battery life is a cherished commodity. Such may not be true for tablets that can stand to have larger batteries and where performance at "some reasonable expectation" of battery life may be the more important. http://equipmentbds.blogspot.com/">please visit it
The same strategy enabled high-EER air conditioning: use a small compressor which runs most of the time plus a larger one to handle peak cooling loads, rather than an even bigger compressor which cycles on and off frequently.
> I was once a programer when i was in High School. Since then I've noticed and been told friend who are programers/coders that programming languages now are sloppy when it comes to memory.
Garbage-collection performs better when there is more memory available, and many modern languages use garbage-collection. Then we have JIT, which requires a bytecode-compiler and a bytecode-interpreter to be in memory (unless you compile the whole program on startup). Basically we're trading memory for things like safety, platform-independence, and performance (e.g. when caching data). Which usually makes a lot of sense and works very well for powerful systems with a lot of RAM, but not so much in other situations.
> I've heard also that old languages like Basic, C and other were better at keeping memory processing needs to a minimum.
What do you mean by 'memory processing needs'?
> Would a modern language using the smaller memory/processing requirement help things with ever need come with more efficient chip?
Sorry, I can't parse 'help things with ever need come with more efficient chip'.
If you're asking if a theoretical language that uses less memory and (magically) less processing power would remove the need for more efficient chips the answer is 'no'. The advantages of being more efficient are cumulative so until we arrive at the point where our phones have 100-year battery times having both would always be better than having one or none.