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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-26 05:27:07

On 26 May 2015 at 14:19, Gavin Lambert wrote:

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

Spot on.

The key part is that it is possible for the compiler to reduce it to 
a mov $5, %eax if *and only if* the compiler knows that is safe.

In other words, no non-trivial destructors, or atomic writes, or 
anything else forcing the compiler to emit unnecessary code even in 
the most unrealistic use cases. My earlier bug was that I was 
constructing an unnecessary exception_ptr, and that forced generation 
of a few hundred unnecessary opcodes. Most of the time in real code 
that will need to be generated anyway, but it doesn't absolve me from 
eliminating it when it's possible to do so especially if it's a one 
line fix (which it was).

The main purpose of the above is for smoke unit testing to have the 
CI tell me when I've written code which interferes with maximum 
optimisation. And, I would assume, whatever poor fellow within the 
clang optimiser team who gets assigning to fix the clang optimiser - 
this code example is a good thing to fix compiler bugs against.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/