[erlang-questions] Parallel Shootout & a style question

Kenji Rikitake kenji.rikitake@REDACTED
Thu Sep 4 08:44:28 CEST 2008


The number of parallel (simultaneously running) Erlang processes affect
a lot to the total execution time and CPU usage.  So I think programmers
have to be careful and should tune the numbers of parallel processes for
a specific task to get the most out of the given number of CPU cores and
nodes.

On the other hand, adding some examples of parallel mapping functions
into OTP will help beginners to learn and use parallelism.

I've written a small piece of code for my own experiments, available at:

http://code.google.com/p/nsplit/

FYI
Kenji Rikitake

In the message <14f0e3620809020052x5c05b9a5s6a3f8ab5177e0a89@REDACTED>
dated Tue, Sep 02, 2008 at 09:52:18AM +0200,
Gleb Peregud <gleber.p@REDACTED> writes:
> Maybe it is good idea to include something like
> http://code.google.com/p/plists/ into Erlang/OTP? It will probably
> introduce more less tuned software created by developers, but it will
> make programming multi-core systems much more easier and fun for
> beginners.




> 
> On Tue, Sep 2, 2008 at 9:42 AM, Mats Cronqvist <mats.cronqvist@REDACTED> wrote:
> > Kevin Scaldeferri wrote:
> >> First,  I don't think it's been mentioned here, but the language
> >> benchmarks shootout finally got some multi-core hardware!
> >>
> >> http://shootout.alioth.debian.org/u64q/
> >>
> >> At the moment, though, there are almost no submissions of parallelized
> >> code, so the results are about the same as the existing hardware.
> >>
> >> I figured (slightly spurred on by the Haskell community) that we
> >> should try to submit some modified versions that actually use the
> >> multiple cores.  So, for example, I made a slight change to the binary
> >> trees code and got a nearly 2x speedup on my 2-core machine.  In doing
> >> so, I did run into one of those little things that I've never really
> >> known the preferred approach for.  My modified function looks like this:
> >>
> >> depthLoop(D,M) when D > M -> ok;
> >> depthLoop(D,M) ->
> >>      Self = self(),
> >>      spawn(fun() ->
> >>                    N = 1 bsl (M-D + ?Min),
> >>                    io:fwrite("~w\t trees of depth ~w\t check: ~w~n",
> >>                              [ 2*N, D, sumLoop(N,D,0) ]),
> >>                    Self ! done
> >>            end),
> >>      depthLoop (D+2,M),
> >>      receive done -> done end.
> >>
> >>
> >>
> >  i'm partial to the monitor-exit idiom. gets rid of the Self for one thing.
> >
> >  mats
> >
> >  depthLoop(D,M) when D > M -> ok;
> >  depthLoop(D,M) ->
> >   erlang:spawn_monitor(fun()-> slave(D, M) end),
> >   depthLoop (D+2,M),
> >   receive {'DOWN',_,_,_,done} -> done end.
> >
> >  slave(D, M) ->
> >   N = 1 bsl (M-D + ?Min),
> >   io:fwrite("~w\t trees of depth ~w\t check: ~w~n",
> >         [ 2*N, D, sumLoop(N,D,0) ]),
> >   exit(done).
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://www.erlang.org/mailman/listinfo/erlang-questions
> >
> 
> 
> 
> -- 
> Gleb Peregud
> http://gleber.pl/
> 
> Every minute is to be grasped.
> Time waits for nobody.
> -- Inscription on a Zen Gong
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions



More information about the erlang-questions mailing list