Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO

Subject: Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
From: Andreas Schäfer (gentryx_at_[hidden])
Date: 2015-08-25 02:26:59

On 14:15 Mon 24 Aug     , Niall Douglas wrote:
> On 24 Aug 2015 at 7:37, Andreas Schäfer wrote:
> > In "Complexity
> > guarantees" some of the minimum complexities exceed their maximum
> > counterparts (e.g. "51 opcodes <= Value transport <= 32 opcodes").
> > What's that supposed to mean? What is the rationale behind citing
> > minimum complexities? And why do you measure opcodes instead of, say,
> > time?
> 
> Monad is designed to be as absolutely as lightweight as possible, and
> is per-commit CI tested to ensure it generates no more than X opcodes
> per operation.
> 
> Traditional complexities such as O(N) make no sense for Monad. No
> operation it does isn't constant time. You're really testing how
> friendly Monad is to the compiler optimiser (which is very friendly).

OK, but how is the number of opcodes relevant in any practical
setting? I for one expect the compiler to generate fast code. And if
that means that one horribly slow instruction gets replaces by 10 fast
ones, then so be it. I'd suggest to set up performance tests which
measure time or throughput for sets of typical workloads.

I'm still unsure what "51 opcodes <= Value transport <= 32 opcodes" is
supposed to mean.

> > Since you mentioned monads were basically identical: why don't you
> > just use std::future?
> 
> AFIO has never been able to return a plain std::future because of the
> lack of standardised wait composure in current C++ i.e.
> when_all(futures ...). It returns an afio::future<> which internally
> keeps a unique integer which looks up stored continuations in an
> unordered_map. This let AFIO implement continuations on top of
> std::future.

OK, this explains why you're using afio::future instead of
std::future, but not why afio::future relies on afio::monad instead of
std::future. AFAICS basic_monad doesn't add much over future's API,
except for get_or() and friends. But those functions aren't being used
anyway, right?

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

> That means AFIO can drop the internal unordered_map, and become
> a pure Concurrency TS implementation with no workarounds and more
> importantly, no central locking at all. That will eliminate the last
> remaining synchronisation in AFIO, and it will be a pure wait free
> solution.

So, is AFIO composable with other parallel code? Could I use it along
with other threads?

Thanks!
-Andreas

-- 
==========================================================
Andreas Schäfer
HPC and Grid Computing
Department of Computer Science 3
Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany
[phone]
PGP/GPG key via keyserver
http://www.libgeodecomp.org
==========================================================
(\___/)
(+'.'+)
(")_(")
This is Bunny. Copy and paste Bunny into your
signature to help him gain world domination!