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: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-05-29 18:19:05

On Fri, May 29, 2015 at 11:14 PM, Niall Douglas <s_sourceforge_at_[hidden]>
wrote:

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