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
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