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> 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/
