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-26 21:41:30

On 26 May 2015 at 19:29, Hartmut Kaiser wrote:

> Optimizing away one allocation to create a promise/future pair (or just a
> future for make_ready_future) will have no measurable impact in the context
> of any I/O, be it wait free or asynchronous or both. 

No one here is claiming better futures make any effect on i/o 
performance except you. You are reading only the parts of the thread 
you want to in order to believe what you already believe (apparently 
that I have some master plan of "taking over" Boost). You drew the 
link here between i/o and futures, none of us claimed it. The thread 
earlier was clearly about two entirely separate topics. You conflated 
them to make your own personal point.

> In general, all I'm hearing on this thread is 'it could be helpful', 'it
> should be faster', 'it can be important', or 'makes a big difference', etc.
> I was hoping that we as a Boost community can do better! 

Constant cherry picking of thread topics just to nay say and put down 
any discussion of alternative idioms and designs isn't being positive 
nor helpful.  

> Nobody so far has shown the impact of this optimization technique on a real
> world applications (measurements). Or at least, measurement results from
> artificial benchmarks under heavy concurrency conditions (using decent
> multi-threaded allocators like jemalloc or tcmalloc). I'd venture to say
> that there will be no measurable speedup (unless proven otherwise). 

Again nobody claimed that. I was quite clear I primarily want single 
op code reduction as part of unit testing. That's its main purpose 
for me as a per-commit CI test that I am writing perfectly optimal 
code, not just mostly optimal code. A happy consequence is a 
potential runtime cost optimal monadic transport, and that's what I 
came here to bikeshed a name for, and see if there is interest in 
such a development. Feedback on both has been both positive, and 
useful, so I will proceed.

I have also been very clear that this new design solves my major 
problems, not *the* major problems with existing futures. That's what 
I designed it to do. I believe it also solves the same problems as 
face futures in ASIO. Once finished and deployed, if others find it 
solves their problems too then it has a great chance on becoming a 
next gen Boost future. If it doesn't, then it won't.

I have been working on this replacement future design since October, 
with multiple presentations of my code experiments here to gain 
feedback. Others have presented their code experiments here too. We 
have all reviewed each other's design ideas and code, and evolved our 
own designs and code in response. If this exchange of code 
experiments between people all with similar problems with existing 
futures isn't what Boost is exactly all about, then I don't know what 
negative and cynical vision of Boost you have. Multiple people here 
have problems with futures, and multiple people are experimenting 
with improvements. This is something that should be welcomed, not 
constantly put down with negativity.

I would expect you'll see me present benchmarks here in due course 
once the implementation is drop in replaceable. I am expecting about 
a 5% performance improvement in AFIO as a drop in, and a 20% 
improvement once I replace AFIO's continuations infrastructure with 
.then() and remove the central spinlocked unordered_map. This should 
help further close the gap between AFIO and ASIO which is currently 
between 15% and 32%. That gain is what I am developing these futures 
for after all - to solve my problems, and maybe as a happy 
consequence solve other people's problems too.

Niall

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