[Bug libstdc++/51618] New: synchronous futures are slow

[Bug libstdc++/51618] New: synchronous futures are slow

[dave at boostpro dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618

             Bug #: 51618
           Summary: synchronous futures are slow
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dave@boostpro.com


Created attachment 26133
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26133
demo

The attached program demonstrates; if you compile with -DNO_SYNCHRONOUS_FUTURE
it will run much faster.  I don't know if this should be considered a
performance bug or not, but it seems to me that in principle it should be
possible to make synchronous futures much faster than that; they could
type-erase an object with no attached synchronization, right?

[Bug libstdc++/51618] synchronous futures are slow

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-19 11:51:52 UTC ---
Could you expand on what you mean by "no attached synchronization"?

If a global future visible to all threads stores a deferred function then it
still needs synchronization to ensure only one thread can invoke the deferred
function and that other threads will wait for it to complete.

std::async is not meant to be the fastest or most flexible solution, it's meant
to be a simple way to exploit a limited amount of concurrency, without breaking
the Kona compromise.  Better solutions are suitable for TR2.

[Bug libstdc++/51618] synchronous futures are slow

[dave at boostpro dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618

--- Comment #2 from Dave Abrahams <dave at boostpro dot com> 2011-12-19 12:11:33 UTC ---
on Mon Dec 19 2011, "redi at gcc dot gnu.org" <gcc-bugzilla-AT-gcc.gnu.org>
wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618
>
> --- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-19 11:51:52 UTC ---
> Could you expand on what you mean by "no attached synchronization"?

There's not much to say.  "Attached" is probably superfluous.

> If a global future visible to all threads stores a deferred function then it
> still needs synchronization to ensure only one thread can invoke the deferred
> function and that other threads will wait for it to complete.

I'm confused.  IIUC even shared_futures aren't supposed to be accessed
concurrently from multiple threads.  Why would multiple threads be
accessing a single plain future?

> std::async is not meant to be the fastest or most flexible solution, it's meant
> to be a simple way to exploit a limited amount of concurrency, without breaking
> the Kona compromise.  Better solutions are suitable for TR2.

I know it's not supposed to be the fastest, but it seems as though it
can be optimized.  If a trivial parallel mergesort using async can run
3x faster than it does now, that's a huge win for users: it means they
can put off trying complex and/or dangerous alternatives.

[Bug libstdc++/51618] synchronous futures are slow

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-19 13:13:32 UTC ---
(In reply to comment #2)
> I'm confused.  IIUC even shared_futures aren't supposed to be accessed
> concurrently from multiple threads.  Why would multiple threads be
> accessing a single plain future?

future::wait() and shared_future::get() are const member functions, so must not
introduce data races if called from multiple threads (17.6.5.9
[res.on.data.races]). So it doesn't matter _why_ someone might want to do that,
they're not forbidden from doing so and therefore we have to provide some level
of internal synchronization to prevent data races.

I'm not claiming the current implementation is optimal but I don't think we can
just turn off all synchronization for deferred functions, and identifying if we
can make specific changes for deferred functions is not high on my priority
list.  I'd rather spend time replacing the mutex-protected
std::unique_ptr<Result_base> with a std::atomic<Result_base*>, which could
benefit all uses of futures rather than just the deferred async case. Although
maybe sub-optimal the current mutex-based impl has the advantage of (relative)
simplicity because the unique_ptr manages the result's lifetime and the mutex
is also used by the condition_variable that signals when the result becomes
ready.

If you have specific suggestions for improving anything then I'll be happy to
hear them, but don't expect me to work on this otherwise, sorry.

[Bug libstdc++/51618] synchronous futures are slow

[dave at boostpro dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618

--- Comment #4 from Dave Abrahams <dave at boostpro dot com> 2011-12-19 13:24:16 UTC ---
Not a problem; thanks for looking.

[Bug libstdc++/51618] synchronous futures are slow

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement