I'd not dismiss the big.LITTLE approach, though the challenges in supporting this scheme in software and OS level are far from trivial as pointed out. Using the ever-increasing (but hard-to-power) number of transistors to add more specialized processing cores is also a great approach and easier to support in software/developer level.
There's a great paper called "Is dark silicon useful?: harnessing the four horsemen of the coming dark silicon apocalypse" by Michael B Taylor of UCSD, where two of the "horsemen" (the "dim horseman" and the "specialized horseman") correspond to two of the approaches here. Recommended reading for getting a better feel of what may lie ahead for the processor world.
The NIH syndrome not withstanding, there is validity to Mr. Renduchintala's point about core optimization, that too application-specific core optimization where Q certainly knows its turf better than ARM.
@Rick: I too suspect there's debate inside Qualcomm about licensing its cores, it is not just the revenue but proliferation of its technology.
I see the real message here being choice, the choice to have a big.LITTLE system, a 4PLUS1 system, an aSMP system, or even a good old fashioned basic DVFS/Sleep system.
It wasn't that long ago postings were whether more than 1 CPU could be used... today I have seen 8 cores being used in andriod, agreed these are not all 'big' tasks so whether you provide them a LITTLE cpu, or a cpu running more slowly with aSMP - the software complexity is pretty much the same.
Lets all just be thankfull we don't all need to eat a single DVFS based solution!
January 2016 Cartoon Caption ContestBob's punishment for missing his deadline was to be tied to his chair tantalizingly close to a disconnected cable, with one hand superglued to his desk and another to his chin, while the pages from his wall calendar were slowly torn away.122 comments