2014/1/11 Hartmut Kaiser
It would be interesting to see this number when giving 1..N cores to the scheduler.
Things like contention caused by the work stealing or by NUMA effects such when you start stealing across NUMA domains usually overshadow the memory allocation costs. Additionally, the quality of the scheduler implementation affects things gravely.
You might want to compare the performance of your library with other existing solutions (for instance TBB, qthreads, openmp, HPX). The link I provided above will give you a set of trivial tests for those. Moreover, we'd be happy to add an equivalent test for your library to our repository.
after re-reading I have the the impression that there is a misunderstanding. boost.fiber is a thin wrapper over coroutines (each fiber contains on coroutine) - the library schedules and synchronizes fibers (as requested on the developer list in 2013) in one thread. the fibers in this lib are agnostic of threads - I've only added some support that the classes (mutex, condition_variable) could be used in a multi-threaded context. combining fibers with threads should be done in another, more sophisticated library (at higher level). I believe you can't and shouldn't compare fibers with qthreads, TBB or openmp. I'll write a test measuring the overhead of a fiber running in one thread (as already described above) first.