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.