Tuesday 30th June 2015 2.48pm

Tue, Jun 30, 2015

I have the first set of benchmarks for lightweight non-allocating monadic futures ready which are 98% compliant with the forthcoming ISO Concurrency TS for C++1z (essentially they are missing std::allocator support for obvious reasons). 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 transport 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> which is a future optional<T> subclassing option<T> which is a basic_monad configured with only T or empty, and that should be dramatically faster than future<T> as we can skip the exception and error transport code entirely. 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.