
Parallel merge sort in Erlang - arjunb
http://yarivsblog.com/articles/2009/03/09/parallel-merge-sort-in-erlang/
======
sketerpot
It looks like Erlang is the language in which I can just spawn processes
withou even thinking about the overhead, and maybe it'll help me out if I have
multiple processors or cores. Is that true? Or rather, to what extent is that
true?

How well does Erlang scale to small, medium, large, and obscene numbers of
processor cores?

~~~
tb
Generally speaking, that's true. The standard practise in Erlang is to treat
processes like you'd treat memory allocation in other languages - don't be
wasteful, but don't spend too much time worrying about it until it becomes a
problem. Processes are cheap.

If you've got a task that seems overly complicated, maybe you're trying to do
two things at once; simplify it by splitting it into two processes. (Of course
then you have to manage the interaction of the two processes, but each is
simpler than your original process, so often this is a net win.)

If your processes are truly doing things in parallel, not just spending their
lives waiting for each other, then you will get speedups with more processes -
minus some overhead for process spawning communications, but this depends on
how parallelisable your problem is. Close-to-linear speedups are not unheard
of, especially if you have lots of mostly-independent problems to process.

~~~
jonke
Agree. I think Yariv for once violets the erlang law ;) This is not big
computations && small communications (-> time_to_write_some_spawn_code) but
"simple sort on numbers" which isn't that big computations so to distribute
that will not give a time performance gain, as he already discovered.

