
The Mobile CPU Core-Count Debate: Analyzing the Real World - msh
http://www.anandtech.com/show/9518/the-mobile-cpu-corecount-debate
======
valarauca1
The debate about non-symetric RISC cores feels like a tech battle that was
already fought in the 2k10's. Amusingly its nearly the exact same debate this
time around. The only difference is 2 orders of magnitude of TDW really, and
Google is now playing Oracle.

You say to Oracle, _Yeah T4 SPARC64 RISC chips look nice. But coding against
non-symetric asychronous cores is hard._

Oracle counters, _Yup, that is why we wrote /maintain the Java JIT that does
that for you!_.

Now Google is selling ARMv8 with A57 non-symetric asynchronous RISC chips,
which you optimize with Java and we do this song and dance over again.

Intel, Nvidia, AMD (formerly ATI) solved this problem a long time ago just by
putting the binary logic between the scalar processors and only exposing 1
_scheduler_ to pipeline these smaller weaker cores but make them _pretend_ to
be a single processor to the OS/User.

~~~
twoodfin
Apple's recent decision to promote LLVM bitcode as a canonical binary form for
apps ("promote" meaning mandatory on the watch) makes me suspicious they're
planning something similar in their future A-series or S-series chips.

The paired relationship between the phone and watch could probably benefit
from either side being able to do a little computation and coordination
without having to spin up the big cores.

There, of course, I'd expect Apple to make it developers' problem to designate
which thread(s) could operate in a limited environment.

~~~
pjmlp
> There, of course, I'd expect Apple to make it developers' problem to
> designate which thread(s) could operate in a limited environment.

Less so when using task queues, I guess.

~~~
twoodfin
Sure, but I'd expect that Apple would provide some API for you to designate
certain tasks as intended to be run in the "Deep Background". With the
understanding that such tasks are on a very short leash power and capability-
wise, and may be arbitrarily cancelled—like iOS's forcible app killing, but at
a smaller grain. (Does GCD have a facility for the dispatcher to unilaterally
do this already?)

------
faragon
In my opinion Qualcomm got it right when they told about better cores instead
more cores, despite they are now shipping 8-core SoCs, too. The rationale of
that decision comes from how difficult is doing "4 good cores" tuned for both
energy-saving and high performance (e.g. Krait 400/450 in Snapdragon 800
series is an impressive design, very optimized stuff for being able to use
very high clocks and fine-grained frequency scaling for battery saving). The
point of 4 complex cores and 4 simpler cores (or 8 simple cores) is just
because simpler core area is tiny in comparison of the total silicon: you get
them almost "for free", and in many cases could outperform the complex
counterpart (unless we get someday cores with dynamic pipelines being able to
work both in-order and out-of-order, who knows).

I hope Qualcomm gets back to 4-core designs with a custom ARM v8 optimized
implementation (2.5-3GHz with independent CPU core frequency and voltage
dynamic control).

P.S. "Snapdragon --Better Cores, Not More Cores" video:
[https://www.youtube.com/watch?v=qdauwqhmsas](https://www.youtube.com/watch?v=qdauwqhmsas)

------
acd
The manufacturers of mobile phones creates CPUs and GPUs that are optimized to
win benchmarks but if you rerun the tests over a longer time period the
CPU/GPU will overheat and run into thermal throttle issues. Thus consumers are
thinking they are buying a phone which is faster than what they really get in
practise.

Then marketing wants new features to sell to consumers so you increase the
core count which is one way of making the phone faster but at the same time
you drain the battery a lot faster.

~~~
Symmetry
Most of the time when I'm using a phone I'm doing something intensive
(rendering a web page) followed by long periods of light use (reading the web
page). So I think that running fast for a short period is a good thing for
phones to be doing.

And making a phone faster will almost neccesarily drain the battery faster.
The important metric is task energy where you multiply the time it takes a
phone to do some task by the power it consumes while doing it to figure out
how much energy was needed overall to do it. By that metric adding more cores
usually has less of a negative effect than speeding up a phone by upping the
clock speed or the size of the OoO structures.

