Re: [boost] [Fibers] Performance

Subject: Re: [boost] [Fibers] Performance
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2014-01-15 18:03:13

> > IMHO, Boost.Fiber is a library which - unlike other Boost libraries -
> > has not been developed as a prototype for a particular API (in which
> > case I'd be all for accepting subpar performance). It clearly has been
> > developed to provide a higher performing implementation for an
> > existing API. That means that if Oliver is not able to demonstrate
> > superior performance over existing implementations, I wouldn't see any
> > point in having the library in Boost in the first place.
> 
> Strongly disagree with your assumption. To me it's the semantics of
> Boost.Fiber that matter.

The semantics are well defined by the C++11 Standard, no news here.

> Before launching any code on a new thread, both Boost.Thread and
> std::thread require that you must sanitize that code against potential
> race conditions. With a large, ancient code base, that sanitizing effort
> becomes almost prohibitive. Running one thread with multiple fibers is
> guaranteed to introduce no new race conditions.

If that's the case, then why does Boost.Fiber provide synchronization
primitives to synchronize between fibers and support for work stealing? Or
why is it implemented using atimics all over the place? Your statement does
not make sense to me, sorry.

> Emulating the std::thread API is intended to minimize coder confusion
> -- not to provide a drop-in replacement.

That's only one particular use case. Clearly we're talking about two
different viewpoints where mine focusses on a very broad application for
this kind of library, while yours is trying to limit it to a small set of
use cases. While I accept the validity of these use cases I think it's not
worth having a full Boost library just for those.

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu