[erlang-questions] Re: Classification of concurrency patterns

Vlad Dumitrescu vladdu55@REDACTED
Wed May 19 10:12:50 CEST 2010


On Wed, May 19, 2010 at 09:51, Joe Armstrong <erlang@REDACTED> wrote:
> 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.
>
> 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).
> ...
> 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.

Please correct me if i misunderstand, but either you have some
concurrency to exploit or you don't. It doesn't matter if the hardware
has 4 or 44 cores.

IMHO, the first step is (as you started to do) to identify
concurrency. There might be several overlapping and incompatible
alternatives - this is where the current hardware becomes interesting
because different solutions will work on it with different efficiency
grades. In other words, to "special case for 4 cores" implies that
there's something more general available.

best regards,
Vlad


More information about the erlang-questions mailing list