Re: [boost] [Fibers] Performance

Subject: Re: [boost] [Fibers] Performance
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2014-01-13 22:51:48

2014/1/11 Hartmut Kaiser <hartmut.kaiser_at_[hidden]>

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