Re: [C++0x] a better <future>

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

2009/6/18 Jonathan Wakely:
> 2009/6/18 Benjamin Kosnik:
>> FYI please put the tests you are using to make these kinds of decisions
>> into testsuite/peformance. Assuming you were testing on linux?
>
> Yes, I will do some performance comparisons on some other arch's using
> the gcc compile farm, but the performance difference on linux was
> significant (2.5 times slower) so I gave up on the atomic version.  I
> assume the reason is that linux mutexes and condvars are already very
> well-tuned whereas the <cstdatomic> code is less mature.
> The performance test was quite artificial: several threads constantly
> polling a future for readiness to intentionally create contention,
> then one thread setting the value, but I'll tidy it up for inclusion.
> Testing any other parts of the interface would only test the
> performance of waiting on a condvar, copying the result, or throwing
> exceptions, so I only tested the performance of is_ready() and
> set_value().

I've attached a test as described above, which I plan to check in to
testsuite/performance/, and in fact for that simple test on linux  the
version using an atomic_address is faster than the version using a
mutex lock, but I think for now it's safer to rely on the <mutex> code
rather than <cstdatomic>.

I have a more complicated test using several promises at once, but not
really suitable to check in, which is where I see the 2.5 times
slowdown using atomic_address.  Cachegrind shows order of magnitude
more L1 cache reads in the atomic_address version.  I plan to
investigate further at a later date.

I'll do the check in tomorrow.

Jonathan

Attachment: polling.cc
Description: Text document