Boost logo

Boost :

Subject: [boost] Lightweight futures (was: Re: Final lightweight monad, next gen futures and upcoming AFIO review (was: Re: [next gen fu
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-06-30 10:44:44


On 26 Jun 2015 at 2:11, Niall Douglas wrote:

> This weekend I'll get started on lightweight future-promise which
> derives from monad and indeed is also a basic_monad but with
> different implementation policy class. These future-promise ought to
> be 98% compatible with the WG21 Concurrency TS spec and will be able
> to participate in hetereogeneous when_any/when_all i.e. you can mash
> them in with std::future.
>
> It'll likely take me a week to come up with some benchmarks comparing
> std::future and my future in a 4-SHA256 engine so you can see the
> benefits of the new design. After that I'll replace AFIO's
> std::future with these lightweight futures in its public API, and we
> should be ready to rock for the 17th July when AFIO's review begins.

I have the first set of benchmarks for lightweight non-allocating
futures ready. They aren't final, but they are representative of what
to expect as compared to the STL future-promise. Note these futures
are configured with a *superset* of the facilities of STL
future-promise, so you have all your monadic programming goodness in
there as a lightweight future inherits from basic_monad plus you can
return error_code as well as exception_ptr:

clang 3.7 libstdc++ 4.9: about 3x faster single threaded (~260 CPU
cycles versus ~780) and 3.2x faster multithreaded.

GCC 5.1 libstdc++ 5.1: about 3x faster single threaded (~260 CPU
cycles versus ~780) and 3.7x faster multithreaded.

VS2015: about 6.8x faster single threaded (~243 CPU cycles versus
~1668).

For shared_future things aren't as good due to the shared_ptr.
However:

clang 3.7 libstdc++ 4.9: about 2x faster single threaded (~380 CPU
cycles versus ~780).

GCC 5.1 libstdc++ 5.1: about 2x faster single threaded (~380 CPU
cycles versus ~780).

VS2015: about 2 faster single threaded (~750 CPU cycles versus
~1433).

These are worst case improvements. My next step is future_option<T>,
and that should be dramatically faster than future<T>. I definitely
know it will be at least around the 100 CPU cycle mark, the question
is how much lower I can push it. I'll know in a few days.

Gory detail can be found at
https://github.com/ned14/boost.spinlock/blob/master/Readme.md.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/



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