[erlang-questions] Re: Classification of concurrency patterns

[Nicolai Waniek]

[ forwarding my mail here, as it happened that I did not reply to the
list but to Joe direclty :) ]




On 05/19/2010 09:51 AM, Joe Armstrong wrote:
> Well of course you're right, in a way and wrong. It's actually the old
> argument about
> top-down programming in a new guise. In top-down programming you're
> not supposed to know
> what the hardware can actually do. But a quick peep under the covers
> isn't a bad idea
> if you want to write efficient code.

Quite possibly the correct 'solution' (if there is any) of providing a
list of different parallelism pattern is in describing the different
algorithms or patterns used first in a rather mathematical way, looking
at the theoretically possible throughputs or problems that arise and in
a second step looking at the drawbacks that arise with the hardware.

Though this is a bit unrelated as it is not erlang-centered, here's an
example: Though there are lots of parallel algorithms described for
shared memory machines [1], the descriptions are mostly theoretical and
when it comes down to implementing the algorithm, say for GPGPU, you
have severe drawbacks by the concrete underlying hardware. So what
happened to me when searching for a GPGPU algorithm to a rather hard
problem was that the theoretical view helped me to figure out which
already available algorithms would fit and I had an idea on where to
look for, but the lack of description of the problems that arise on
different hardware solutions put me back some time researching how to do
stuff.

In conclusion: Think about describing the patterns in two parts (for
each pattern):

1. Theoretical Pattern
  When it comes down to this, every pattern is usually either divide and
conquer or task parallelism. It is quite often possible to determine the
worst case time the algorithm would require for different theoretical
setups.

2. Practical Limitations
  This part should mention current (as in 'our hardware at the moment is
this, we don't know what it will be in 10 years') hardware limitations
and quite possible statistics of different problem sizes so that a
reader could decide if the parallelism will be the best way for the
problem at hand.


Describing a parallel pattern should always mention that one has to
figure out if the problem will be best solved in parallel.


regards,
	Nicolai


 [1] http://techreports.lib.berkeley.edu/accessPages/CSD-88-408.html