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/