Boost logo

Boost :

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
> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk