[erlang-questions] Parallel Shootout & a style question

Richard A. O'Keefe <>
Fri Sep 5 02:11:40 CEST 2008


I am all for automatic parallelisation, AS LONG AS IT WORKS.

There are ways of dealing with the "but it might be a long
list with little per-element work" issue; we might have
something to learn from the Cilk people here.  However,
there is a big difference between a "fibre" created by the
run time system to do work in parallel and a "process"
created by the programmer to work concurrently with other
processes and communicate with them.

"Fibres" may be created or *not* at the runtime's whim,
and work may be shifted around in various ways because there
is no *visible* communication to be affected by it.

I am going to keep on repeating my basic point until it
sinks in:  Erlang processes have side effects, and changing
from sequential map to parallel map changes the meaning of
the program.  I offer you just one example:

     f(N) ->
         Pid = spawn(fun loop/0),
         [Pid!{I,self()} || I <- lists:seq(1, N)],
	Pid!stop,
	[receive X -> X end || I <- lists:seq(1, N)],

     loop() ->
        receive
            stop -> stop;
            {X,Pid} -> Pid!(X*X-3), loop()
        end.

If you "automatically parallelise" the first list
comprehension (or the equivalent map I was too lazy to
write), it will go wrong.  The answers computed by
loop/0 will be sent to the wrong processes.

Automatic parallelisation is good for PURE functional
code.  When we have something that can reliably detect
chunks of Erlang code that are pure, let's go for it!
Till then, beware...






More information about the erlang-questions mailing list