Re: [Caml-list] Current state of threading parallelism?

[Wolfgang Draxinger <wdraxinger.maillist@draxit.de>]

On Fri, 04 Oct 2013 17:44:27 +0200
Francis Dupont <Francis.Dupont@fdupont.fr> wrote:

> => yes, this is the official way (no shared memory, no fine grain
> locking, etc). Note this was the way followed by Python too for
> the same reasons (to make the intepreter multi-threaded was considered
> as too hard for the expected best result, i.e., ~4 time maximum speed
> up).

Well, there are certain problems that can be largely parallelized in a
way that performance scales well with the number of cores. Those
problems usually also perform in constant memory (of course this is all
mutable state then, so not really pure). I'm thinking of problems that
could be put as well on GPUs here, like signal decomposition, error
diffusion models, stuff like that.

> => I can't see where a LLVM backend really helps for multi-core/multi-
> processor parallelism... IMHO the best / most reasonable thing you can
> do to handle multi-core/multi-processor parallelism is a set of
> communicating independent OCaml instances (one per process). The model
> is well understood and scales.

I consider the LLVM backend exciting, because it promises to increase
the range of architectures that can be targeted natively. Me mentioning
it had nothing to do with parallelism.


Wolfgang