Boost logo

Boost :

Subject: Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-25 10:47:54

On 25 Aug 2015 at 16:32, Andreas Schäfer wrote:

> > I have those too, of course. Have a look at
> >,
> > bottom of the document.
> Thanks. Is the benchmark code for this available online so I can see
> what was actually measured?

Of course:

> > > I'm still unsure what "51 opcodes <= Value transport <= 32 opcodes" is
> > > supposed to mean.
> >
> > Min/max code bloat for a monad<int> or future<int>.
> So the minimum is 51 and the maximum is 32?

Correct. That non-sensical outcome is due to definition. The minimum
code bloat _should_ result from a known-memory outcome where the
compiler knows for a fact memory has some value, and therefore can
prune branching down to no code output at all. The maximum code bloat
is where memory has unknown state, and therefore the compiler must
generate all possible branches for that unknown state.

Compiler optimisers are not as deterministic as perhaps they should
be, so you get this weird outcome where the compiler generates more
bloat for the known case than the unknown case. Which is a compiler
optimiser bug, strictly speaking.

> > i.e. all lightweight futures are also lightweight monads. Just
> > asynchronous ones.
> So this architecture makes it easy to define different "future-ish"
> types. Got it. I've seen code blocks like this...
> > #define BOOST_MONAD_FUTURE_POLICY_ERROR_TYPE stl11::error_code
> > #define BOOST_MONAD_FUTURE_POLICY_EXCEPTION_TYPE std::exception_ptr
> > #include "detail/future_policy.ipp"
> > #define BOOST_MONAD_FUTURE_POLICY_ERROR_TYPE std::error_code
> > #include "detail/future_policy.ipp"
> > #include "detail/future_policy.ipp"
> ...which, if I'm not mistaken define future, future_result and
> future_option. Same for monad, monad_result and monad_option. Of these
> only future and monad seem to be used in boost.monad, and only future
> is actually in use by boost.afio.

Yep, that's code which stamps out many policy class implementations
using the preprocessor by reincluding the same base policy
implementation with macros reconfiguring it. I got bored maintaining
many separate policy classes, so I automated a single solution.

> This leads me to the question: why this complicated architecture, if
> you only really rely on future?

Monad is designed as a useful library on its own. AFIO only uses part
of it.

> > > > Monad contains a full Concurrency TS implementation, and works
> > > > everywhere in any configuration and currently with far lower
> > > > overheads than any existing STL implementation by a big margin (about
> > > > 50%).
> > >
> > > That's a big claim. Do you have performance tests to back it up? Which
> > > which implementation did you compare your results?
> >
> > See the benchmarks posted earlier. I compared to libstdc++ 5.1 and
> > Dinkumware VS2015.
> Do you happen to have a link handy? I must have missed that post.

End of the Readme file!


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at