On Fri, May 29, 2015 at 11:14 PM, Niall Douglas
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.
Absolutely! However, what is proposed in this thread is hardly usable in any context where concurrent operations may occur. What you missed is the message that it is not memory allocation or the existance of exception handling code that makes the futures "slow". In fact what makes futures slow is the mechanism to start asynchronous tasks (If you have the finest task granularity you can imagine). Having a single SHA round behind a future makes little to no sense ...
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.
It is of course not stupid to have as lightweight futures as possible. What's stupid is the assumption that your task decomposition has to go down to a single instruction on a single data elemtn. Well, it is at least stupid on today's architectures (SIMD, caches etc.). So yes, grain size is important, not only to overcome any overheads that are associated with spawning the asynchronous task but also executing its work (I hope AFIO doesn't fetch data from disk one single byte at a time just because the future might be able to handle it).
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost