By: anon (anon.delete@this.anon.com), December 8, 2014 11:37 pm
Room: Moderated Discussions
Jouni Osmala (josmala.delete@this.cc.hut.fi) on December 8, 2014 1:10 pm 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
>
> I'm assuming that 90+% of programs already run fast enough and they don't matter for this.
Of course. That is the basic starting point for any such discussion. There is no point talking about programs where CPU performance is already more than adequate, in the context of increasing CPU performance. That's self evident.
> Its all about asking question in what use current computers are too slow , and can you parallerize
> that or are those cases already parallel. And I'm assuming you can parallerize atleast 10%
> of those times where user waits CPU for long enough to actually notice it.
>
> > 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.
>
> Its more like would you rather have todays quad i7 or 10-20% faster single core?
No, it's not at all. I am not claiming that there is *no* use for multi core. Going from 1->2 cores gave a reasonably good return even for clients. Going 2->4 was far less but still a little bit. But diminishing returns hit extremely quickly in the client space.
We're talking about from this point forward. Going from 4->8 cores would give less than 10-20% real performance increase. So the choice between 10-20% faster quad core, or an 8 core device, then obviously the quad core is the better option.
> The power management is that
> good for turbo mode that you really cannot expect to be much faster for limiting number of cores.
Well that is true to an extent yes. They do take up silicon and interconnect, but if cores can be treated as "dark silicon", and don't take up much space from cache and other dedicated logic, then yes it can make sense to add more to the device.
But that is *already* reqiured to reach 4 cores in the client space. Even 2, really. If those cores could not share TDP then 4 is already too many for client, and probably most would even prefer a single core than 2 cores.
But that doesn't mean the *future is parallel*. It means we are getting more cores not because they are problem solving workhorses, but because they sometimes can grab some high hanging fruit. In that sense they fit with other exotic and complex single thread optimizations to chase after every tenth of a percent.
> And other
> question is would you rather have in the future 16 cores or 4 cores that are 20% faster?
4 cores, of course. Even on my PC that I often run parallel make jobs on and therefore probably have more parallel work to do than 95% of PC users.
> That's what that all
> the time shrinking and following the trends will give later trade offs, of course there will be big improvement
> with on chip memory on single thread performance but that same improvement will give even bigger improvement
> on parallel and isn't either that or parallel but both, but kind of improvements that allow you to choose between
> doubling number of cores and adding that amount of resources per core are limited by both diminishing returns
> and the latency that comes from having bigger structures, think about P4 prescott in terms of branch missprediction
> penalty on that one, and think how fast that would be in random spaghetti code, it would be fast in vectorizable
> straight line code and that would even better be served by wider SIMD or more cores.
>
> You normalize too early.
No I didn't. I normalized at the optimal time for parallelism gains! 1->2 cores. There will be no time better to see gains from parallelism.
Single thread performance increases may be on a downward trend, but so are parallelism increases. In 10 years from now, taking the sum of the average work performed by client devices, is the performance gain going to be greater with parallelism improvements or with single thread improvements? It could go either way, I think. Certainly it's not obvious that parallel would be a clear winner (my money is personally on serial).
> First i7 was first that combined most of the already known ways to
> make things faster, after that it's been 10% per generation from tweaking.
> And latest tweaking
> included widening the core from 6-8 wide and lots of other improvements and still 10% and
> at same time power per core has gone down significantly which allows adding more cores but
> Intel chose integrating GPU and reducing power consumption and cooling requirements.
>
> As for what has done with client everyone seems to be integrating the ultimate parallel accelerator
> (GPU) to CPU, and add wider vectors, which is related to my claim that future is parallel just
> because its only way for serious gains as long as we are working with current physics.
Well if the GPU is integrated into the CPU, then you could *say* that parallel CPU work will be significantly increased. But the fundamental work is not much changed, it will just be a side-effect of integration. Normal integer code will not magically start running on those cores. Most likely they will be like dark silicon and remain off until there is GPU work to be done on them.
> which is related to my claim that future is parallel just
> because its only way for serious gains as long as we are working with current physics.
It's been 10 years and most client workloads do not make effective use of 4 cores. Exactly what kind of serious gains do you imagine there will be from here on?
That's the thing. You're accusing software people of being myopic and ignoring hardware realities, but now you are just ignoring the realities of the software. These "serious gains" are in your imagination.
> > > > > 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
>
> I'm assuming that 90+% of programs already run fast enough and they don't matter for this.
Of course. That is the basic starting point for any such discussion. There is no point talking about programs where CPU performance is already more than adequate, in the context of increasing CPU performance. That's self evident.
> Its all about asking question in what use current computers are too slow , and can you parallerize
> that or are those cases already parallel. And I'm assuming you can parallerize atleast 10%
> of those times where user waits CPU for long enough to actually notice it.
>
> > 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.
>
> Its more like would you rather have todays quad i7 or 10-20% faster single core?
No, it's not at all. I am not claiming that there is *no* use for multi core. Going from 1->2 cores gave a reasonably good return even for clients. Going 2->4 was far less but still a little bit. But diminishing returns hit extremely quickly in the client space.
We're talking about from this point forward. Going from 4->8 cores would give less than 10-20% real performance increase. So the choice between 10-20% faster quad core, or an 8 core device, then obviously the quad core is the better option.
> The power management is that
> good for turbo mode that you really cannot expect to be much faster for limiting number of cores.
Well that is true to an extent yes. They do take up silicon and interconnect, but if cores can be treated as "dark silicon", and don't take up much space from cache and other dedicated logic, then yes it can make sense to add more to the device.
But that is *already* reqiured to reach 4 cores in the client space. Even 2, really. If those cores could not share TDP then 4 is already too many for client, and probably most would even prefer a single core than 2 cores.
But that doesn't mean the *future is parallel*. It means we are getting more cores not because they are problem solving workhorses, but because they sometimes can grab some high hanging fruit. In that sense they fit with other exotic and complex single thread optimizations to chase after every tenth of a percent.
> And other
> question is would you rather have in the future 16 cores or 4 cores that are 20% faster?
4 cores, of course. Even on my PC that I often run parallel make jobs on and therefore probably have more parallel work to do than 95% of PC users.
> That's what that all
> the time shrinking and following the trends will give later trade offs, of course there will be big improvement
> with on chip memory on single thread performance but that same improvement will give even bigger improvement
> on parallel and isn't either that or parallel but both, but kind of improvements that allow you to choose between
> doubling number of cores and adding that amount of resources per core are limited by both diminishing returns
> and the latency that comes from having bigger structures, think about P4 prescott in terms of branch missprediction
> penalty on that one, and think how fast that would be in random spaghetti code, it would be fast in vectorizable
> straight line code and that would even better be served by wider SIMD or more cores.
>
> You normalize too early.
No I didn't. I normalized at the optimal time for parallelism gains! 1->2 cores. There will be no time better to see gains from parallelism.
Single thread performance increases may be on a downward trend, but so are parallelism increases. In 10 years from now, taking the sum of the average work performed by client devices, is the performance gain going to be greater with parallelism improvements or with single thread improvements? It could go either way, I think. Certainly it's not obvious that parallel would be a clear winner (my money is personally on serial).
> First i7 was first that combined most of the already known ways to
> make things faster, after that it's been 10% per generation from tweaking.
> And latest tweaking
> included widening the core from 6-8 wide and lots of other improvements and still 10% and
> at same time power per core has gone down significantly which allows adding more cores but
> Intel chose integrating GPU and reducing power consumption and cooling requirements.
>
> As for what has done with client everyone seems to be integrating the ultimate parallel accelerator
> (GPU) to CPU, and add wider vectors, which is related to my claim that future is parallel just
> because its only way for serious gains as long as we are working with current physics.
Well if the GPU is integrated into the CPU, then you could *say* that parallel CPU work will be significantly increased. But the fundamental work is not much changed, it will just be a side-effect of integration. Normal integer code will not magically start running on those cores. Most likely they will be like dark silicon and remain off until there is GPU work to be done on them.
> which is related to my claim that future is parallel just
> because its only way for serious gains as long as we are working with current physics.
It's been 10 years and most client workloads do not make effective use of 4 cores. Exactly what kind of serious gains do you imagine there will be from here on?
That's the thing. You're accusing software people of being myopic and ignoring hardware realities, but now you are just ignoring the realities of the software. These "serious gains" are in your imagination.