Subject: Re: [boost] [next gen future-promise] What to call the monadic return type?
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2015-05-26 13:24:56
> 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
> > except for demonstrating some impressive compiler optimization
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk