[erlang-questions] Re: Classification of concurrency patterns

[Joe Armstrong]

On Wed, May 19, 2010 at 2:39 AM, Robert Virding <rvirding@REDACTED> wrote:
> On 18 May 2010 11:46, Joe Armstrong <erlang@REDACTED> wrote:
>> ...
>>
>> There's no point in expressing the concurrency in an algorithm if the
>> hardware can't do it anyway
>> (or perhaps there is?)
>
> Yes, there is. If the algorithm is best expressed in a concurrent way
> then you should definitely do so, even if the hardware can't do it.
> You are saying what you mean. Or it can be a hint to the
> implementation, for example using pmap instead of map means that you
> feel that the arguments can be evaluated in parallel, it is then up to
> the implementation/hardware to do it if possible.
>
> Robert
>

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.

My current problems are about efficiency and not elegance. The elegant
solution is not
fast enough. There is no apparent natural concurrency to exploit.
Sequential code
that is not fast enough must be speeded up - so we have to find bits
of concurrency in
the middle of the sequential code and map it onto exiting hardware
(warts and all).

Now I guess the high road to do this would be to describe the problem
in a super high level
and then use correctness preserving transformations with hints as to
the pragmatics of
the underlying hardware. The problem, here is that we want the
solution a year ago, and
nobody knows how to walk the high road (well not quite, but this road
is also long and winding,
more of a trail in the forest than a road)

So far explicit reasoning "we have 4 cores, let's special case it like
this" is the only approach
that yields faster systems - we don't have enough experience to
generalise the results and
which is worse, each new generation of multi-cores has different
properties (in terms of inter-core
message passing times etc. ...)

We want to make the stuff go faster on the hardware we have, not write
elegant SW for
hardware that doesn't exists.

(( Do both then - Yea ))

/Joe