big.LITTLE is ARM's solution to a particularly nasty problem: New process nodes no longer deliver the kind of overall power consumption improvements that they did prior to 2005. Prior to 90nm, semiconductor firms could count on new chips being smaller, faster, and drawing less power at a given frequency. Eight years ago, 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 every single node. Rising defect densities have already created a situation where -- for the first time ever -- 20nm chips won't be cheaper than the 28nm processors they're supposed to replace. This is a critical problem for mobile, where low power consumption is absolutely vital. big.LITTLE is ARM's answer to this problem...
big.LITTLE: ARM's Strategy For Efficient Computing
That was a great read, thanks!
These articles have been great so far, very informative.
I hadn't realized the full logic behind what Nvidia did with the Tegra 3 Chip, having a quad core chip with a 5th "Ghost or backup core"
If you have a DVFS system on a big.LITTLE configuration its only real effective use would be inside each individual chip, it would have a range of effectiveness for the A-15 and another range of effectiveness for the A-7. This opens up a low energy/perfect amount of computing power balance that is unmatched, unless.....
Unless this sort of methodology is a band-aid fix for a larger problem. Using both methods adds another layer of inefficiency that could be cut down with a lot of fine tuning.
The problem with that is while fine tuning occurs helping bring the big.LITTLE/DVFS config up to par you might be left in the dust entirely by a new innovation.
A strangely common occurrence in this industry. I believe they call it opportunity cost.
Great, but I think you need SMARTER software also ... much smarter, and LEARNING.
A lot of stuff can be turned off when you turn off (or timeout) the display. You probably do not need xG, WiFI, Bluetooth connectivity all the time when the display is turned off. The best would be if the phone would learn from your use of the phone. If the phone learns that you seldom reed gmail instantly when email arrives, should the phone than be less aggressiv polling the servers when the display is black? I think so. Than only a few manual "overrides" where the "learnings" are wrong would be needed to fit your usage pattern.
One manual "override" I would like to have is connecting the "display off" button on my Android phone to "closing all my open GUI apps". That would free up memory and avoiding the garbage collector CPU hogs when memory hits the wall. Closing the apps would be smarter.
Nice article, very intriguing. I'm interested to see how this kind of technology building is built upon in the future.
NEWS TIPS |
This site is intended for informational and entertainment purposes only. The contents are the views and opinion of the author and/or hisassociates. All products and trademarks are the property of their respective owners. All content and graphical elements areCopyright © 1999 - 2014 David Altavilla and HotHardware.com, LLC. All rights reserved. Privacy and Terms