big.LITTLE: ARM's Strategy For Efficient Computing
Conclusion: Is big.LITTLE a kludge?
The last point we want to talk about is one that ARM hotly refutes -- the idea that big.LITTLE, far from being a vital part of the company's strategy, is a patch designed to fix a problem. Problem being: The Cortex-A15 is more processor than modern smartphones can handle very well. There's some accuracy to that last statement -- the Nexus 4 runs faster if you drop it in a freezer. Cortex-A9 designs didn't really have that problem.
ARM's literature always made it clear that the Cortex-A15 wasn't really meant for most phone applications; the company initially showcased it as fitting into the top of the smartphone line, but with a greater role to play in tablets and other larger devices. All the same, much of the work being done on the Cortex-A15 is focusing on bringing power consumption down. That's because vendors that want to use ARM's own design rather than building a Cortex-A15 "class" product like Qualcomm's Krait or Apple's Swift, need a design that can compete with those chips in both areas.
After talking to ARM and looking over the data the company provided, I don't think big.LITTLE was a last-minute attempt to shoehorn Cortex-A15 into lower power envelopes. I suspect instead that big.LITTLE's implementation has proven more difficult than ARM anticipated, while the first Cortex-A15 products also drew somewhat more power than first anticipated. If we step back and look at the big picture, however, major shifts in microprocessor technology typically don't land gracefully.
Once Global Task Scheduling is functional, it can be used to boost performance over and above the A15 cores alone
Intel's first out-of-order microprocessor architecture, the Pentium Pro, debuted to lackluster sales. Windows 2000 and Windows XP didn't properly support Intel's SpeedStep initially, and Hyper-Threading wasn't fully supported until Windows XP SP1. AMD debuted its new 64-bit architecture in 2003, but the market didn't start seriously adopting 64-bit Windows until 2009. It takes time, and effort, for software development to catch hardware, and so it's not particularly odd that big.LITTLE adoption is a bit clunky at the moment.
Once Bay Trail and a refreshed set of big.LITTLE devices ship (hopefully with GTS support directly baked into the kernel), we'll be able to get an idea of where these two approaches stand when compared against each other. big.LITTLE has real promise in the long run, but adoption will hinge on a great many factors -- some of which ARM can't control.
ARM's literature always made it clear that the Cortex-A15 wasn't really meant for most phone applications; the company initially showcased it as fitting into the top of the smartphone line, but with a greater role to play in tablets and other larger devices. All the same, much of the work being done on the Cortex-A15 is focusing on bringing power consumption down. That's because vendors that want to use ARM's own design rather than building a Cortex-A15 "class" product like Qualcomm's Krait or Apple's Swift, need a design that can compete with those chips in both areas.
After talking to ARM and looking over the data the company provided, I don't think big.LITTLE was a last-minute attempt to shoehorn Cortex-A15 into lower power envelopes. I suspect instead that big.LITTLE's implementation has proven more difficult than ARM anticipated, while the first Cortex-A15 products also drew somewhat more power than first anticipated. If we step back and look at the big picture, however, major shifts in microprocessor technology typically don't land gracefully.
Once Global Task Scheduling is functional, it can be used to boost performance over and above the A15 cores alone
Intel's first out-of-order microprocessor architecture, the Pentium Pro, debuted to lackluster sales. Windows 2000 and Windows XP didn't properly support Intel's SpeedStep initially, and Hyper-Threading wasn't fully supported until Windows XP SP1. AMD debuted its new 64-bit architecture in 2003, but the market didn't start seriously adopting 64-bit Windows until 2009. It takes time, and effort, for software development to catch hardware, and so it's not particularly odd that big.LITTLE adoption is a bit clunky at the moment.
Once Bay Trail and a refreshed set of big.LITTLE devices ship (hopefully with GTS support directly baked into the kernel), we'll be able to get an idea of where these two approaches stand when compared against each other. big.LITTLE has real promise in the long run, but adoption will hinge on a great many factors -- some of which ARM can't control.
