[erlang-questions] Re: Classification of concurrency patterns

[Joe Armstrong]

No no no ....

Thus spake the great progenitors

   1) first make it right
   2) then make it fast
   3) keep it right while making it fast

I've done (1) and it wasn't fast enough - now I'm into 2 and 3.

If you point me at a formal and provably correct way of doing 2 and 3
I'll start using it.
Right now we're doing 2 and 3 by hand. When we have enough experience of 2 and 3
we might be able to generalise the results.

This thread started since I wanted to classify the kind of concurrency problems
and put them into tight sub-groups so I could see how they mapped onto the
hardware we have today.

I have a specific problem in mind, at a top level I can use pipeline
concurrency,
but that does not solve the problem since some of the bits in the pipeline are
bottlenecks - and these bits are not naturally concurrent - they use maps etc.
which I could change to pmaps, but this has to be done with great
care, since it could
easily make matters worse.

And as for the good old days I was "obsessed by efficiency" as I am today.

I still strive to make everything "as inefficient as possible" (ie as
beautiful and clear as possible)
subject to the condition that it is "fast enough" - it must of course
be "fast enough and no faster".

'trouble is project managers do not know the meaning of the expression
"fast enough"

/Joe


2010/5/19 Håkan Mattsson <hm@REDACTED>:
> On Wed, May 19, 2010 at 9:51 AM, Joe Armstrong <erlang@REDACTED> wrote:
>
>> We want to make the stuff go faster on the hardware we have,
>> not write elegant SW for hardware that doesn't exists.
>
> Right now it feels rather good that you did not have these
> thoughts in the ancient single core days when the concurrency
> primitives in Erlang was invented. If the main driver for Erlang
> concepts would have been speed and not elegance, I suppose
> that the Erlang language would look quite different. ;-)
>
> /Håkan
> ---
> Håkan Mattsson
> Tail-f Systems
>