ned Productions Consulting


Technology musings by Niall Douglas
ned Productions Consulting
(an expert advice and services company based in Ireland)


Sunday 28th June 2015 3.11am

Link shared: https://ci.nedprod.com/view/Boost%20Thread-Expected-Permit/job/Boost.Spinlock%20Test%20Linux%20GCC%204.8/doxygen/classboost_1_1spinlock_1_1lightweight__futures_1_1basic__future.html

Some preliminary results from my lightweight non-allocating promise-futures which are heading towards Boost later this month as compared to STL promise-futures:

All values are CPU cycles on a i7-3770K @ 3.9Ghz.

## clang 3.7:
### libstdc++ 4.9 future promise:
Simple loop: 761
Producer Consumer: 838
  Creation and setting: 674
  Getting from future: 160
  Destruction of future: 4

### lightweight future promise:
Simple loop: 260
Producer Consumer: 378 (2.22x faster)
  Creation and setting: 281
  Getting from future: 51
  Destruction of future: 46

## GCC 5.1:
### libstdc++ 5.1 future promise:
Simple loop: 726
Producer Consumer: 809
  Creation and setting: 654
  Getting from future: 150
  Destruction of future: 4

### lightweight future promise:
Simple loop: 205
Producer Consumer: 323 (2.50x faster)
  Creation and setting: 227
  Getting from future: 49
  Destruction of future: 48

## VS2015:
### Dinkumware future promise:
Simple loop: 596
Producer Consumer: 1545
  Creation and setting: 752
  Getting from future: 311
  Destruction of future: 482

### lightweight future promise:
Simple loop: 210
Producer Consumer: 311 (4.97x faster)
  Creation and setting: 236
  Getting from future: 37
  Destruction of future: 38

So, when configured with the same featureset as STL promise-futures they are twice faster on clang/GCC, and five times faster on MSVC. Not bad.

As I've said on boost-dev, I want a construct promise - get future - set promise round to fit inside 50 CPU cycles, and therefore become useful for issuing a promise per SHA256 round which is about 480 CPU cycles. These early results are for promise-futures with a superset of STL promise-future features, so they will only get faster. My end goal is a promise-future so lightweight that it is essentially an asynchronous optional<T> i.e. it can carry no exception state at all. I believe that ought to have a reasonable chance of fitting inside my 50 cycle budget.

We'll find out within the week I suspect.