Re: [boost] [Fibers] Performance

Subject: Re: [boost] [Fibers] Performance
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2014-01-16 07:35:07

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

> I still don't get it. There is no API stability question. The API is well
> defined for over 2 years now in the C++11 Standard (and even longer in
> Boost.Thread).

I could have choosen a different API for fibers - but I think the
developers are
more familiar with std::thread/boost::thread API.

> So performance is the main incentive for such a library (what
> could there be else?).

with fibers you can suspend your execution context while keep the thread
running (might execute something else). this is not possible with threads
if they are suspend (yield(), waiting  on mutex/condition_variable).

this feature of fiber enables you to write (again asio eve nif you don't
care this
use case).

for (;;) {
   ...
   boost::asio::async_read( socket_, buffer, yield[ec]);
   ...
}

async_write() suspends the current execution context (not the thread
itself) and
resumes it if all data have been read. without fibers you can't write the
code like
above (for-loop for instance).
in the thread itself you can have more than one fibers running such
for-loops.

with threads you would have to pass a callback to async_read() and you
could not
invoke it inside a for-loop.

the example directory of boost.fiber contains several asio examples
demonstrating
this feature.

> If you don't need the extra performance - use
> std::thread.
>

I could have choosen a different API.

> Boost.Fiber does not add any new semantics beyond what the Standard
> mandates.

it adds 'suspend/resume' a execution context while the hosting thread is
not suspended.

> Instead, it adds more constraints to the context where the API can
> be used (somebody mentioned interaction with Asio, and single-threaded
> legacy applications) - thus it narrows down existing semantics.
>

I think this statement is false.

> Sure, that's out of question. My concern is that we're about to add a Boost
> library targeting some minor use cases only, while it has the potential to
> change the way we do parallel computing.
>

be sure that I've performance on my target after this discussions!
I've already started to write code for performance-measurements.