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: Avi Kivity (avi_at_[hidden])
Date: 2015-05-26 02:05:36

On 05/26/2015 03:14 AM, Niall Douglas wrote:
> On 25 May 2015 at 18:33, Avi Kivity wrote:
>
>>>>> ... turns into a "mov $5, %eax", so future<T> is now also a
>>>>> lightweight monadic return transport capable of being directly
>>>>> constructed.
>>>> Can you post the code?  I'd be very interested in comparing it with
>>>> seastar's non-allocating futures.
>>> I may do so once I've got the functioning constexpr reduction being
>>> unit tested per commit.
>> I'm looking forward to it!  I've been bitten by the same compile time
>> explosion problems and I'm curious to see how you solved them.
> Now fully functional at:
>
> https://github.com/ned14/boost.spinlock/tree/master/test/constexprs
>
> I have the clang and GCC disassembler dumps there too so you can see
> they all reduce to single opcodes on GCC only. clang isn't so good,
> and I'm just about to send a large bug report to LLVM
> (https://llvm.org/bugs/show_bug.cgi?id=23652) followed by email to
> Chandler. The unit testing will later do a diff compare to ensure
> that single opcode reduction always remains so per commit.
>
> VS2015 RC can't cope with exception_ptr being inside an unrestricted
> union, so it doesn't work there yet. I have a hacky macro workaround,
> but I may just wait for VS2015 RTM.
>

Thanks! Our compile time explosions are related to chaining, which isn't 
there yet, so I'll wait for those.

Some notes:
   - get() waits by spinning, how do you plan to fix that? Seems like 
you'd need a mutex/cond_var pair,
     which can dwarf the future/promise pair in terms of size and costs.
   - _lock_buffer isn't aligned, should use a union or aligned_storage 
or something.
   - _is_consuming causes value_storage::reset() to be called, but even 
if !_is_consuming,
     the value will be moved away, effectively consuming it.

Like Peter mentioned, the compiler optimizations aren't related to 
constexpr, but to aggressive inlining.  I expect you'll get the same 
generated code even if you drop all constexpr annotations.