Boost logo

Boost :

Subject: Re: [boost] [Fibers] Performance
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2014-01-11 04:31:30


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

> Oliver,
>
> Do you have some performance data for your fiber implementation? What is
> the
> (amortized) overhead introduced for one fiber (i.e. the average time
> required to create, schedule, execute, and delete one fiber which runs an
> empty function, when executing a larger number of those, perhaps 500.000
> fibers)? It would be interesting to see this number when giving 1..N cores
> to the scheduler.
>

unfortunately I've no performance tests yet - maybe I'll write one after
some optimizations (like replacing the
stl containers by a single linked list of intrusive_ptr).

I'm not sure what a fiber should execute within such a test. should the
fiber-function have an empty body
(e.g. execute nothing)? or should it at least yield one time?
if the code executed by the fiber does nothing then the execution time will
be determined by the algorithm
for memory allocation of the clib. the context switches for resuming ans
suspending the fiber and the time
required to insert and remove the fiber from the ready-queue inside the the
fiber-scheduler.
this queue is currently a stl container and will be replaced by a
single-linked list of intrusive-ptrs.
a context switch (suspending/resuming a coroutine) needs ca. 80 CPU cycles
on Intel Core2 Q6700 (64bit Linux).


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk