Subject: Re: [boost] [Fibers] Performance
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2014-01-15 16:31:00
> > 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.
> As I explained several times in this review - boost.fiber aims to provide
> a way to synchronize/coordinate coroutines as it was requested on the dev-
> list some months ago.
> -> boost.asio
In that case you might be surprised to learn that libraries often have a
life of their own which opens up unexpected opportunities way beyond
whatever you might have imagined. IHMO it is a mistake to constrain
Boost.Fiber to just what you said as this is only a minor use case (as
convenient as it might be) for such a library.
Threading with minimal overheads supporting fine grain parallelism is the
future. Building convenient means for managing that parallelism is the
future. Application scalability, which today might be just a problem for
high end computing problems, gains footprint in everyday computing at an
exceptionally high rate. Two years from now, my desktop will support 288
concurrent threads (Intel Knight's Landing ). Massive multi-threading is
here to stay.
At the same time, application scalability is limited by the 4 horsemen of
the apocalypse : Starvation, Latencies, Overheads, and Waiting for
contention resolution (SLOW). IOW, minimizing overheads is one of the
critical pieces of the puzzle. Libraries such as Boost.Fiber are critical to
solve the problems of insufficient scalability and parallel efficiency
achievable by using existing technologies only.
Wake up Oliver - you're up to the forefront of parallel computing and you
don't realize it!
Boost has to define the future of C++ libraries (as imposed on us by the
computer architectures to come), it has not to focus on covering the past.
Let's not let this opportunity slip.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk