Re: [boost] [Fibers] Performance

Subject: Re: [boost] [Fibers] Performance
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2014-01-16 08:22:28

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

But you have not (and for a good reason!). So this argument is moot.

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

The only benefit you're getting from using fibers for this (and you could
achieve the same semantics using plain ol'threads as well, Boost.Asio is
doing it for years after all) is - now guess - performance. So please make
up your mind. Are you trying to improve performance or what?

> > If you don't need the extra performance - use std::thread.
> >
> 
> I could have choosen a different API.

As said, you didn't. So this is moot.

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

Who cares about this if not for performance reasons. However I still
believe, that Fibers _are_ threads. You can't do anything with them you
couldn't do with std::thread directly (semantically).

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

Care to elaborate? Why is this false? You're implementing the Standards API
with Standards semantics and constrain the usability of the outcome to a
couple of minor use cases. Sorry, still no new semantics.

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

Performance is never an after-thought. Your implementation quality so far is
not up to Boost standards (as others have pointed out), the performance of
the library is not convincing either. I'd suggest you withdraw your
submission at this point, rework the library and try for another review once
that's achieved. We have more substandard code in Boost already than
necessary because of this 'let's fix it later' attitude. This 'later' never
happens, most of the time - sadly.

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