Samsung will tear the wraps off an eight-core ARM processor in February although half of the chip will spend most of its life asleep. The architecture is called big.Little, which ARM presented in October last year. Four cores run software all the time if they can, and the other four are only powered up when the user launches a …
More cores so their phones can look more advanced to the specification sheet spotters, the mobile phone equivalent of train spotters.
My laptop only has two cores and seems to cope well. It is the speed of the core that is more important than how many of them you have. Given many multi-core chips tend to be clocked lower is seems fairly pointless.
If you want your device to be more responsible how about writing more of the code in C++ and stop using virtual machines with garbage collection (that tends to kick in at the wrong moment).
RE: code in C++
But this implies use of both low level system APIs and high level GUI libraries for C++ , and I think these are not currently available on the majority of phones. Would be great if they were, though.
Perhaps RIM (BB 10 and Microsoft (WinRT) efforts will help here a little, but they do not exactly set the trends ...
Yes agreed (for the most part). Beyond being unnecessary, it's a bit of a kludge. Yes there are two distinct modes of use but it still seems they are opting for a bit of a Frankenstein's monster. When it is described as "half asleep" I guess the implication is the device will switch between A7 and A15 "mode" rather than use both at the same time (which would be a considerable power drain when there are diminishing returns on the application of additional cores for most processing tasks). Not sure though. Perhaps that will be precisely what they plan to do. Either way it rather seems to be a tacit acceptance the A15 is a shade too power hungry for general mobile use. Given the resources they have, I would have thought they would be better off going all in and rolling their their own fully custom design.
According to the specs of a few months ago it can switch between A7 & A15 in some 20 ms, it can also run both at the same time. It seems to brilliant way of getting low power & high performance out of the same kit.
I wonder how long before Intel comes out with a big.Little equivalent - if it can tread around the patents that ARM presumably has.
"If you want your device to be more responsible how about writing more of the code in C++ and stop using virtual machines with garbage collection (that tends to kick in at the wrong moment)."
If I was looking at making a device more responsible, I'd make sure it was home early and didn't spend all it's money on tobacco, gambling. hard liquor and loose women.
Build it and they will come...
Re: RE: code in C++
You *think* wrong.
If you'd ever tried debugging application in Android you'd know just how quickly java method calls find their way into native C++. Sure, there are performance critical things that you are better not implementing in Java, and which there are no C++ APIs for. A very small proportion of the software running on a Android phone is actually running in the VM.
Rather, the problems with Android have traditionally been a lack of coherent use of hardware acceleration and lack of bad behaviour of apps - in part due to the lack the strong-arm policy controlling what apps can and cannot do that Apple imposes, and Microsoft has copied for Windows RT.
For the sake of completion - it's worth pointing out that Objective-C is garbage collected and there isn't a direct C++ API for the GUI in iOS either (although ObjectiveC and C or C++ are toll-free bridged, and plenty of the APIs are in fact C).
It's a good thing that everyone who uses C++ to write code for WP8 devices is sufficiently well disciplined in using its manual memory allocation/deallocation that they never have a memory leak. Otherwise the phone might randomly reboot due to some hard to identify background process(es).
Re: RE: code in C++
"For the sake of completion - it's worth pointing out that Objective-C is garbage collected and there isn't a direct C++ API for the GUI in iOS either (although ObjectiveC and C or C++ are toll-free bridged, and plenty of the APIs are in fact C)."
Objective-C isn't garbage collected on iOS and is only optionally garbage collected when compiling for the Mac. On iOS you have to allocate your own mem for objects and deallocation is achieved through reference counting. More recent releases of iOS support ARC. (Automatic Reference Counting) which gives the best of both worlds, the powerful control over memory that is useful for an embedded system device, whilst being very close to the ease of use garbage collection provides (though I do feel sorry for new programmers who will never learn manual memory management. Life will be a bitch when they come accross the rare instances where it is still useful to understand the manual methods of memory management but they don't have experience in it). Not sure why there would be any need for a C++ API, when Objective-C is a pure superset of C and a sibling of C++ (so in general no slower, though in Objective-C object method calls are acheived using messaging which *is* a little slower. However that's where being a superset of C is useful, because you can just use C functions instead for any performance critical tight loops).
Yes it is inefficient, that's the point. The number of transistors that can be thrown at a problem is limited only by their power consumption and/or heat production.
The A15 is a modern out-of-order speculative execution CPU with deep pipelines for fast clock speeds. Those out-of-order speculative instruction decode transistors are on all the time, unlike other units of the CPU like floating point, vector math, encryption that can be turned off when not used. So yes the A15 draws more power than the current A9. But not double the draw, for a certain task the a15 may be able to wake up, complete the task and sleep quicker than the a9 saving power. Ie twice the performence maybe 1.5 times the power draw.
The a7 is a remarkable core, performance is almost as good as current a9, but using less power and taking up less silicon area. Those 4 A7 cores take of the real-estate of one a15 core.
So with transistors to burn, why not add the a7 cores, if that's all you need to use 90% of the time?
I'd like to see this implemented into future laps which are more suitable for games. Touch screen games are not for me. Battery life should be pretty good too.
This is real innovation.
More cores is innovation? Using two different types of cores just as ARM had specified is innovation?
I guess if I had a three bedroom house and I added another bedroom you'd consider that innovation as well.
Given that most dual core phones already have one of those cores idle (and in some cases completely switched off) eight cores seems completely and utterly unnecessary - even in the context of VMs utilitising processing power...
Was that a public announcement by Samsung? I think Appla has a patent on these...
(as for it being useless, having a lot of cores is very useful in the case of heavily-parralelizable tasks, such as calculating polygons for 3D rendering. Hence the 3D games reference, presumably).
seems a very sensible idea, use low power cores for most of the work, wake up the other cores as needed...
if the OS is written well, and apps have a separate ui thread/process, then the phone can stay very responsive but lower power consumption!
Doesn't the Tegra have something similar to this? I can't remember where I might of read it, possibly here, but I'm sure that the quad core Tegras in the N7 have 5 cores, 1 low power core and the 4 main cores that are used when needed.
Similar in intent
The fifth 'companion' core in the Tegra is the same A9 design as the other 4... but it uses a different fab process (not sure what it's called - low power, high efficiency or something similar) that cuts its power consumption but also limits its clocks.
This will probably be the first real big.LITTLE (as ARM calls it) implementation... with different core designs that are completely coherent.