[erlang-questions] Parallel Shootout & a style question

Kenneth Lundin kenneth.lundin@REDACTED
Tue Sep 2 17:07:03 CEST 2008


We have no plan to change the lists functions to be automatically
parallell under the hood by
spawning of the execution into several Erlang processes.
We can not detect in runtime by automatic if it pays off to be
parallell for e.g. a lists:map.
If it pays off depend on many factors such as size of input list,
current number of processes in the system etc. For example if we have
a telecom system where each "call" is represented as
one or several Erlang processes and the system supports 10 000
simultaneous calls then there
would be no point trying to parallellize a lists:map which possibly
might be performed by
many of these "call" processes at the same time.

Therefore we intend to leave it to the programmer to be explicit about
parallellism.
We can do this by adding new functions in lists or in a new module,
functions like
pmap, psort etc.

/Kenneth Erlang/OTP team, Ericsson

On Tue, Sep 2, 2008 at 4:30 PM, Mats Cronqvist <mats.cronqvist@REDACTED> wrote:
> Hynek Vychodil wrote:
>>
>>
>> On Tue, Sep 2, 2008 at 12:21 PM, Mats Cronqvist
>> <mats.cronqvist@REDACTED <mailto:mats.cronqvist@REDACTED>> wrote:
>>
>>     Hynek Vychodil wrote:
>>
>>         I'm not sure if it is good idea at all. If F function is very
>>         cheap and result or parameter is large (copy of it is more
>>         expensive in comparison to F expense) parallel version of pmap
>>         can be slower than serial version even many cores is used.
>>         Developer should be able control size of parallelized bunch
>>         and switch off parallel process fully. For example pmap(fun(X)
>>         -> [0|X] end, [lists:seq(1,1000000)]) is really bad idea and I
>>         will not be happy if lists:map will be changed to pmap
>>         automatically at default ;-)
>>
>>      regardless of how the OTP libs behaves, it will always be
>>     possible to find some case for which it performs badly. the
>>     question is what the *default* behavior should be.
>>      it seems obvious to me that the target for the OTP libs should be
>>     non-trivial calculations on multi-core machines. motivation;
>>
>>
>> Lists module is component of stdlibs which is OTP library/aplication
>> so I can't be agree with you. Lists is often used and lists should
>> behave nice in normal usage.
>
>  define "normal."
>
>> Change lists:map to anything other than current is bad. There are OTP
>> libs which could not be performace beaters as gen_server, gen_fsm and
>> other, but there are OTP libraries which should be. For example stlib!
>> I guess you forgot that stdlib is OTP library too.
>
>  well, now that you mention it, stdlib being part of OTP does sound
> vaguely familiar.
>  alas, i still think the normal case should be optimized for multicore.
>
>  mats
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>



More information about the erlang-questions mailing list