Jouni Osmala (josmala.delete@this.cc.hut.fi) on December 8, 2014 2:45 am wrote:
> > >
> > > or people using DAGs to explain why reference count is a solid
> > > solution when complex object graphs typically have cycles
> >
> > Oh, I agree. My example was the simple case. The really complex cases are much worse.
> >
> > I seriously don't believe that the future is parallel. People who think you can solve it with compilers
> > or programming languages (or better programmers) are so far out to lunch that it's not even funny.
> >
> > Parallelism works well in simplified cases with fairly clear interfaces and models. You find
> > parallelism in servers with independent queries, in HPC, in kernels, in databases. And even
> > there, people work really hard to make it work at all, and tend to expressly limit their models
> > to be more amenable to it (eg databases do some things much better than others, so DB admins
> > make sure that they lay out their data in order to cater to the limitations).
> >
> > Of course, other programming models can work. Neural networks are inherently very
> > parallel indeed. And you don't need smarter programmers to program them either..
> >
> > Linus
>
> Future is parallel in one way or another, simply because diminishing returns on improving serial

This always starts off a heated debate every time it comes up.

But here goes again: *There are diminishing returns on improving parallel*.

Assuming we're talking about client computing here (Linus already ruled out HPC and databases).

Why would you assume the inefficiencies of parallel model will be solved, but the serial ones will not? I can understand being pessimistic on both, or optimistic on both, but why different positions on each one? It's not like parallel computing is a relatively new unexplored garden of low hanging fruit and breakthroughs waiting to happen.

Client computing has gone from 1 to 2-4 cores in the last 10 years. Perhaps 6-8 at the very high end and then double thread count for SMT, but based on where the vast majority of devices are, and the applications being run on them, it would be a stretch to say that multicore has increased the acutal realized client CPU performance by more than 4x. On average I would say significantly less than 2x would be more likely, due to not having parallel work available much of the time.

In the same time, it looks like single thread performance has increased roughly between 2-4x (Athlon XP 3200+ to today's Core i7). Again there are also outliers like vectorizable FP and some memory bandwidth bound cases where performance is closer to 10x, but we'll also discard those. But the thing about this performance increase is that it's *usable* for all CPU work, not just parallel work.

So I would say that on a client workload, just from pure performance standpoint (obviously not power or cost etc), then almost all the time you would actually prefer to have a single core, limited to single thread Core i7-4790K over a hypothetical quad core Athlon 3200+ from 10 years ago. Single thread gains have still matched or outpaced parallel gains on client devices since multicore was introduced.

Same pattern for mobile CPUs, if you take the last mobile CPU core before they went multicore, the Cortex A8, and compare to something like today's Apple A8.