On Sat, 18 Sep 2010 18:08:09 +0200 Dariusz Mazur <dar...@emadar.com> wrote:
> W dniu 2010-09-17 17:49, Mattias Gaertner pisze: > > On Fri, 17 Sep 2010 14:09:59 +0200 > > Dariusz Mazur<dar...@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 -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus