I think it&#x27;s not much of a problem if app high-level logic stays in a relatively slow, single-threaded language. It&#x27;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&#x27;s that you prefer Apple&#x27;s approach of giving the die space to the GPU).<p>My point is that it&#x27;s not necessarily the case that you&#x27;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&#x27;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&#x27;t run the entropy decoder on the GPU no matter what. Yet image decoding parallelizes on multicore CPUs very well.<p>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 &quot;flat design&quot; apps do, is utterly trivial and comes nowhere near to full GPU utilization. So the GPU sits there idle most of the time.<p>The bottom line, to me, is that parallelism&#x27;s just hard. It&#x27;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&#x27; parallelism, except maybe for games. In fact, I worry it actually may end up having the reverse effect.