Re: [boost] Futures (was: Re: [compute] Some remarks)

Subject: Re: [boost] Futures (was: Re: [compute] Some remarks)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-01-05 05:27:33

On 4 Jan 2015 at 11:25, Thomas Heller wrote:

> I absolutely agree. "future islands" are a big problem which need a solution 
> very soon. To some extent the shared state as described in the standard could 
> be the interface to be used by the different islands. What we miss here is a 
> properly defined interface etc.. I probably didn't make that clear enough in my 
> initial mail, but i think this unifying future interface should be the way 
> forward so that different domains can use this to implement their islands.
> FWIW, we already have that in HPX and we are currently integrating OpenCL 
> events within our "future island", this works exceptionally well.

I personally think that any notion of any shared state in futures is 
one of the big design mistakes. Instead of "future as a shared_ptr", 
think "future as a pipe".

> > 2. Every time you touch them with change you unavoidably spend
> > thousands of CPU cycles due to going through the memory allocator and
> > (effectively) the internal shared_ptr. This makes using futures for a
> > single SHA round, for example, a poor design despite how nice and
> > clean it is.
> 
> I am not sure i fully understand that statement. All I read is that a 
> particular implementation seems to be bad and you project this to the general 
> design decision. I would like to see this SHA future code though and 
> experiment with it a bit.

Have a look at 
https://github.com/BoostGSoC13/boost.afio/blob/content_hashing_merge/b
oost/afio/hash_engine.hpp.

The best I could get it to is 17 cycles a byte, with the scheduling 
(mostly future setup and teardown) consuming 2 cycles a byte, or a 
13% overhead which I feel is unacceptable.

The forthcoming hardware offloaded SHA in ARM and Intel CPUs might do 
2 cycles a byte. In this situation the use of futures halves 
performance which is completely unacceptable.

> > 3. They force you to deal with exceptions even where that is not
> > appropriate, and internally most implementations will do one or more
> > internal throw-catches which if the exception type has a vtable, can
> > be particularly slow.
> 
> I think this is a void statement. You always have to deal with exceptions in 
> one way or another ... But yes, exception handling is slow, so what? It's only 
> happening in exceptional circumstances, what's the problem here?

No it isn't. Current futures require the compiler to generate the 
code for handling exception throws irrespective of whether it could 
ever happen or not. As a relative weight to something like a SHA 
round which is fundamentally noexcept, this isn't a trivial overhead 
especially when it's completely unnecessary.

> > This is why Chris has proposed async_result from ASIO instead, that
> > lets the caller of an async API supply the synchronisation method to
> > be used for that particular call. async_result is superior to futures
> > in all but one extremely important way: async_result cannot traverse
> > an ABI boundary, while futures can.
> 
> What's the difference between async_result and a future? I am unable to find 
> that in the ASIO documentation.

As Bjorn mentioned, an async_result is a per-API policy for how to 
indicate the completion of an asynchronous operation. It could be as 
simple as an atomic boolean.

> > Replacing the entire concurrency engine and indeed paradigm in your
> > C++ runtime is, I suspect, too scary for most, even if the code
> > changes are straightforward. It'll be the "bigness" of the concept
> > which scares them off.
> 
> Neither me or Hartmut are proposing to use HPX within boost. However, we want 
> to release a HPX-enhanced C++ stdlib in the near future to account for this 
> exact deficiency.

With respect, nobody wants nor needs yet another STL. We already have 
three, and that already has enough of a maintenance headache.

If you can persuade one of the big three to fully adopt your 
enhancements then I am all ears.

> > To that end, the non-allocating basic_future toolkit I proposed on
> > this list before Christmas I think has the best chance of "fixing"
> > futures. Each programmer can roll their own future type, with
> > optional amounts of interoperability and composure with other future
> > islands. Then a future type lightweight enough for a SHA round is
> > possible, as is some big thick future type providing STL future
> > semantics or composure with many other custom future types. One also
> > gains most of the (static) benefits of ASIO's async_result, but one
> > still has ABI stability.
> 
> I missed that. Can you link the source/documentation/proposal once more 
> please?

Try http://comments.gmane.org/gmane.comp.lib.boost.devel/255022. The 
key insight of that proposal is the notion of static composition of 
continuations as the core design. One then composes, at compile-time, 
a sequence of continuations which implement any combination and 
variety of future you like, including the STL ones and the proposed 
Concurrency TS ones. You will note how the functional static 
continuations are effectively monadic, and therefore these elementary 
future promises are actually a library based awaitable resumable 
monadic toolkit which could be used to write coroutine based Hana or 
Expected monadic sequences which can be arbitrarily paused, resumed, 
or transported across threads.

Universal composure of any kind of future with any other kind is 
possible when they share the same underlying kernel wait object. I 
intend to use my proposed pthreads permit object which is a portable 
userspace pthreads event object as that universal kernel wait object. 
If widely adopted, it may persuade the AWG to admit permit objects 
into POSIX threads for standardisation, that way C and C++ code can 
all use interoperable wait composure.

Indeed, if POSIX threads already had the permit object, then OpenCL 
would have used it instead of making their custom event object, and 
we could then easily construct a std::future and boost::future for 
Compute. Sadly, the AWG don't see this sort of consequence, or rather 
I suspect they don't hugely care.

Niall

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