[Lazarus] Threads in Lazarus code base

[Mattias Gaertner]

On Sat, 18 Sep 2010 18:08:09 +0200
Dariusz Mazur <darekm at emadar.com> wrote:

>   W dniu 2010-09-17 17:49, Mattias Gaertner pisze:
> > On Fri, 17 Sep 2010 14:09:59 +0200
> > Dariusz Mazur<darekm at emadar.com>  wrote:
> >
> >> [...]
> >> Whats about CILK http://en.wikipedia.org/wiki/Cilk
> >>
> >>
> >> |_function_  fib (n: integer):integer;
> >> var
> >>     x,y : integer;
> >> begin
> >>
> >>        if (n<   2)  then exit(n)
> >>        else begin
> >>
> >>           x :=_spawn_  fib (n-1);
> >>           y := fib (n-2);
> >>           _sync_;
> >>           exit(x+y);
> >>       end;
> >> end;
> >> |
> > Have you noticed that most examples for multi threading are either
> > - easy to understand, but completely impractical (the above is an
> >    order of magnitude slower than single threaded)
> I don;t agee. First with CILK approach we deal with task, not threads. 
> Thus we need good task passing to workers.
> But seems, that this approach will be faster because on each SPAWN 
> invoke we add only task (and this is very simple and short function, as 
> add to FIFO queue)
> And each worker (worker count is similar to cores) find task to do. Even 
> when task are very different (shorter and longer) gueue pass task to 
> worker with balancing .   Why You think  this will be magnitude slower I 
> don't know.

Only the first 46 Fibonacci numbers fit into an integer, which a
simple loop can compute. I don't know any task scheduler
that produces less enough overhead to compute this faster.

 
> > - OR practical, but hard to understand
> > ?
> >
> > Note: afaik CILK is the same as parallel loops:
> No. On loop we divide iterations on start loops. When each iteration has 
> different  time of computing, we lost concurrence, because one thread 
> finish, but rest  work.

And how does CILK solve this?


> Second: we not initialize thread on SPAWN (with 
> loops threads are initializing on start loop), Workers wait  for task on 
> idle. Push and pop task from queue can be very fast. Of course this 
> depend on implementation (for example each worker should deal with own 
> queue, but should be possibility to draw task form other queue, this 
> approach is faster than single MPMC FIFO queue)

Ehm, you know that parallel loops normally use thread pools, do you?

 
> > It allows to make some
> > special cases need less typing, can increase readability and can
> > decrease overhead. As always with multithreading: wrongly used it can
> > make code run much slower.
> 
> Multithreading is not only for faster computing.

Does that mean, you agree?

Mattias