Re: [boost] Boost.Fiber review January 6-15

Subject: Re: [boost] Boost.Fiber review January 6-15
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2014-01-11 16:04:45

On Saturday, January 11, 2014 21:48:23 Vicente J. Botet Escriba wrote:
> Le 11/01/14 19:45, Oliver Kowalke a écrit :
> > 2014/1/11 Vicente J. Botet Escriba <vicente.botet_at_[hidden]>
> > 
> >> What would be the advantages of using work-stealing at the fiber level
> >> instead of using it at the task level?
> > 
> > it is very simple because you migate a 'first-class' object, e.g. the
> > fiber
> > already is like a continuation.
> 
> yes, but what are the advantages? Does it performs better? It is easy to
> write them?
> 
> >> I wonder if the steel and migrate functions shouldn't be an internal
> >> detail of the library and that the library should provide a fiber_pool.
> > 
> > fiber-stealing is not required in all cases and it has to be provided by
> > the fiber-scheduler hence it has to be part of the scheduler.
> 
> What i sthe cost of a scheduler supporting stealing respect to one that
> doesn't support it? The performances measures should show this also.

This question can not be easily answered as this is purely application 
specific. Non work stealing schedulers do include less overhead to schedule the 
different threads while work stealing schedulers are able to mitigate certain 
load imbalances, i.e. different execution time of the running tasks.

> 
> >> I'm wondering also if the algorithm shouldn't be replaced by an enum.
> > 
> > sorry -  I don't get it.
> 
> I mean that if the algorithm interface is not used by the user, it is
> enough to have an enum to distinguish between several possible scheduler
> algorithms.
> 
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost