> The 6s and iPad Pro are a good demonstration of the importance of designing systems tastefully. In the rest of ARM-land, manufacturers are enthralled by octa-core designs that take up lots of die space but sit idle in most consumer workloads.
Unfortunately, this kind of thinking has created a real chicken-and-egg problem. I want phones to have more cores. I know how to use them. It's not just "design by specs"; I have actual numbers I've been spending years gathering that show that multicore results in real measurable user experience wins on apps, if those apps are engineered properly.
You're right that, by and large, apps of today do not benefit from multicore. But the ideal solution to that is not going to be to just stop adding cores to phones. It's to fix our apps.
Another way to look at it is: What else are you going to spend the die space on, after all? More space for the GPU? GPU compute is even harder to use than multicore! As a result, consumer apps have even lower GPU utilization than CPU utilization (my last benchmarks in this area pulling up numbers as low as 8%).
Multi-threading is hard, let's go shopping![1] It'd be great if Google Play Store wasn't janky on a modest 1.5 GHz A53, even with eight cores on tap, but if even Google can't do it with their first party apps, what hope do mere mortal app developers have?
[1] And it'll stay that way so long as mobile platforms are based on JS/Obj-C/Java.
I think it's not much of a problem if app high-level logic stays in a relatively slow, single-threaded language. It's the plumbing that can really benefit from parallelism. This is true no matter whether you take the approach of giving your die space to the CPU or the GPU (and if I read your argument right, it's that you prefer Apple's approach of giving the die space to the GPU).
My point is that it's not necessarily the case that you're giving the most benefit to applications by doing that. GPU compute is hard to use—so hard that, to a first approximation, no consumer app anywhere uses it—and there are lots of computationally-intensive tasks that apps want to do that aren't just displaying graphics. Take image decoding, for instance (very important on mobile for obvious reasons). You can run some parts of it on the GPU, but the gains, if any, are modest—and you can't run the entropy decoder on the GPU no matter what. Yet image decoding parallelizes on multicore CPUs very well.
In fact, giving the die space to the GPU hits walls of its own. Most consumer apps have a hard time maxing out the GPU. Mobile GPUs have gotten so powerful that pushing textures around with trivial shaders, which is what typical "flat design" apps do, is utterly trivial and comes nowhere near to full GPU utilization. So the GPU sits there idle most of the time.
The bottom line, to me, is that parallelism's just hard. It's not clear that the recent trend of giving all die space to the GPU instead of using it for CPU cores is actually going to do anything to increase our apps' parallelism, except maybe for games. In fact, I worry it actually may end up having the reverse effect.
Unfortunately, this kind of thinking has created a real chicken-and-egg problem. I want phones to have more cores. I know how to use them. It's not just "design by specs"; I have actual numbers I've been spending years gathering that show that multicore results in real measurable user experience wins on apps, if those apps are engineered properly.
You're right that, by and large, apps of today do not benefit from multicore. But the ideal solution to that is not going to be to just stop adding cores to phones. It's to fix our apps.
Another way to look at it is: What else are you going to spend the die space on, after all? More space for the GPU? GPU compute is even harder to use than multicore! As a result, consumer apps have even lower GPU utilization than CPU utilization (my last benchmarks in this area pulling up numbers as low as 8%).