Re: [boost] [next gen future-promise] What to call the monadic return type?

Subject: Re: [boost] [next gen future-promise] What to call the monadic return type?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-29 17:14:04

On 28 May 2015 at 17:11, Hartmut Kaiser wrote:

> > No one here is claiming better futures make any effect on i/o
> > performance except you. 
> 
> From the AFIO docs: 
> 
> AFIO is 'A C++ library which lets you schedule an ordered dependency graph
> of file input/output operations...'
> (http://rrsd.com/blincubator.com/bi_library/afio/?gform_post_id=938). And
> you said more than once that a) the new 'futures' are 'much' faster and b)
> that you want to use those for AFIO. Go figure.

Perhaps you don't understand the context I meant.

AFIO, being built for the mediocre level of C++ 11 in VS2010 
originally, implemented its own future continuations infrastructure. 
It keeps an internal unordered_map which associates additional 
metadata with each future-promise created for every asynchronous 
operation scheduled. This was done to keep the user facing API and 
ABI clean of implementation details - you could work with 
shared_future<shared_ptr<async_io_handle>> and behind the scenes the 
engine looked that op up in its hash table, and fetched the 
additional metadata which includes the continuations for that future 
amongst other things. It is however not particularly efficient, 
introducing a ~15% overhead for non-continued ops over ASIO and ~30% 
overhead for continued ops over ASIO.

If instead of keeping the per-future metadata in a hash table I could 
keep the metadata in the future itself, I can eliminate the hash 
table and the spinlock which surrounds that hash table. That is a big 
win for the design - much simpler, cleaner implementation, and no 
central locking at all.

Relative to async OS operations, the overhead of the continuations 
implementation is usually, but not always unimportant relative to the 
OS operation. However it is rare you just read and write raw data - 
usually you want to do something to that data as it enters and exits 
storage e.g. things like SECDED ECC or Blake2b hash rounds. This is 
where the overhead introduced by doing a locked hash table lookup 
every time you append a continuation becomes inefficient especially 
if you append many continuations to each op. This is what I am 
fixing. This is what I mean by performance improvements.

There is also cleanliness of design problem - over a year ago as a 
thought experiment I wrote up a SHA256 implementation which issued a 
promise-future once per SHA round. Performance was dreadful obviously 
enough because a SHA round isn't big compared to a promise-future 
cycle, and indeed your colleague Thomas Heller showed exactly the 
same thing for HPX at C++ Now - granularity of task slice has to be 
proportionate to the promise-future cycle overhead.

But it got me thinking about exactly what is so flawed with the 
existing promise-future design, because they *should* be lightweight 
enough that using a promise-future per SHA round isn't a stupid 
design decision. I don't think I am alone in thinking this about 
existing promise-futures.  

> You clearly should decide what you want besides trolling the Boost-devel
> mailing list.

I suspect by trolling you mean me campaigning to persuade the 
community of my vision for Boost's future.

It may involve making a lot of noise, and it is definitely much less 
efficient than simply persuading Dave something needs to happen as it 
used to be. I am also hardly alone in campaigning since Dave left the 
scene. However I am being successful in this persuasion - the recent 
changes in policy announced at C++ Now are all movements in the 
direction of what I have been advocating for years. Perhaps this is 
the real reason why you are pissed.

Niall

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