[erlang-questions] Re: Classification of concurrency patterns

[Sean Hernandez]

I believe more comunications patterns can be found in the following
technical report,

The Landscape of Parallel Computing Research: A View from Berkeley
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.html

On Tue, May 18, 2010 at 7:29 AM, Guy Wiener <wiener.guy@REDACTED> wrote:

> IMHO we need to distinguish between two things: Dependencies and Resources.
>
> Dependencies in a pattern describe the process topology under optimal
> circumstances.  For example, in pmap, there is no dependency between the
> processes. In a pipe, each process depends on the previous. In a star,
> processes depend on a central, long-running process, etc.
>
> Resources, as Joe and Geoff mentioned, describe what is available to the
> application - Namely, the number of processors and their network topology.
>
> The actual instance of the application is the combination: Assigning
> available resources according to the dependencies. Sometime there are
> un-used processes (for example, if the pipe is shorter then the available
> processors). Sometimes the actual assignment is less then the optimal (for
> example, if there are more independent processes then available
> processors).
>
> Guy.
>
> On Tue, May 18, 2010 at 12:54 PM, Geoffrey Biggs
> <geoffrey.biggs@REDACTED>wrote:
>
> > On 18/05/10 18:46, Joe Armstrong wrote:
> > > There's no point in expressing the concurrency in an algorithm if the
> > > hardware can't do it anyway
> > > (or perhaps there is?)
> >
> > I believe there is. It may not be directly applicable to hardware now,
> > but it has a high chance of being applicable at some point in the
> > future. Just make sure it's *implementable* now, even if we don't get
> > all the benefits that having native hardware support would give, like
> > true concurrency.
> >
> > The catch here is that your example of pmap breaking into different
> > sizes depending on the number of cores is the anti-thesis of what a
> > pattern should be. It's specifying implementation details. I think that
> > the patterns should be more abstract than "the task is split up 4 times"
> > - a better description is "the task is split up n times," with n
> > determined by the pattern user for their specific needs - hopefully
> > based on some benchmarking.
> >
> > Geoff
> >
> > ________________________________________________________________
> > erlang-questions (at) erlang.org mailing list.
> > See http://www.erlang.org/faq.html
> > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
> >
> >
>