Version française
Home     About     Download     Resources     Contact us    
Browse thread
Smart ways to implement worker threads
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Goswin von Brederlow <goswin-v-b@w...>
Subject: Re: [Caml-list] Smart ways to implement worker threads
Eray Ozkural <examachine@gmail.com> writes:

> When I'm implementing a parallel/dist algorithm I take care of making
> the communication code abstract enough to be re-used. Since
> abstraction in C derivative languages (function pointers, templates
> etc) are a joke; one need not bother with this as expected future code
> re-use isn't much.
>
> On the other hand in ocaml we have the best module system which can be
> used to create advanced parallel data structures and algorithms. A
> shared mem queue would be among the most trivial of such
> constructs. If we think of world domination we have to see the whole
> picture. Parallel programming is considered difficult because common
> programmers don't understand enough algebra to see that most problems
> could be solved by substituting an operator in a generic parallel
> algorithm template. Or that optimal algorithms could be re-used
> combinatorially (consider the relation of a mesh topology to a linear
> topology with s/f routing)

Yeah. I would love to have all the basic ocaml modules also as a thread
safe flavour.

> The fact is that an efficient parallel algorithm need not be long
> (theory suggests that fastest is shortest). It is our collective lack
> of creativity that usually makes it long.
>
> Cheers,
>
> Eray
>
> Ps: parallelism is not tangential here. I believe it is unnecessary to
> implement asynchronous processes just for the sake of handling
> overlapping I/O and computation. That's like parallelism for high
> school programming class.

I'm a big fan of doing IO asynchronously in a single thread. Given that
ocaml can only run one thread at a time anyway there is usualy no speed
gain in using multiple threads. The overhead of making the code thread
save is big in complexity (if only we hade thread save modules :) and
all you end up doing is waiting on more cores.

The exception is when you offload work to C code that can run within
enter_blocking_section() / leave_blocking_section() and you have enough
work to keep multiple cores busy. For example doing blockwise sha256
sums with 4 cores is 3-3.8 times as fast as single threaded depending on
blocksize.

MfG
        Goswin