On 26/05/2015 13:48, Hartmut Kaiser wrote:
I've got everything working except the sequence:
promise<int> p; p.set_value(5); return p.get_future().get();
This should reduce to a mov $5, %eax, but currently does not for an unknown reason. I'm just about to go experiment and see why.
I asked this question many times before: what is this good for in
practice
except for demonstrating some impressive compiler optimization capabilities? If I need to return the number '5' I'd usually write
return 5;
in the first place...
Generally this sort of pattern comes up when implementing a generic method that is constrained (by base class or concept) to return a future<T>, but where the actual implementation can complete synchronously without waiting (eg. a filesystem API that normally reads data asynchronously, but in this particular case is being implemented by an in-memory filesystem that can reply instantly).
Ok, so what? Just use make_ready_future - done. Do we even know how large the overheads of this are? Or do you just 'assume' for the overheads to be unacceptable? Can I see some numbers from a real world application?
I'm assuming that the code Niall posted isn't literally written like that but is instead produced after inlining such generic method calls for a particular test case.
I doubt any speedup based on all of this fancy-pants optimizations would be even measurable in the context of file system operations. I'm still highly doubtful of all of this. As said, give me a real world use case with real world measurements showing at least some speedup over 'conventional' futures. Otherwise all of this is an empty exercise. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu