[erlang-questions] Re: Classification of concurrency patterns

[Joe Armstrong]

On Wed, May 19, 2010 at 10:12 AM, Vlad Dumitrescu <vladdu55@REDACTED> wrote:
> 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.

In my case the problem is given, and the hardware is given.
It matters very much how many cores there are and their physical
characteristics,
since I have to map the problem onto a set of concurrent processes that
run on the given hardware.


>
> IMHO, the first step is (as you started to do) to identify
> concurrency.

Done that - the #concurrent processes is far greater than the number of cores

> 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.

In my case it's because I have a 4 core computer.

> best regards,
> Vlad
>