Re: Future atomic operation cleanup

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2014-08-22 at 07:00 -0700, Richard Henderson wrote:
> On 08/22/2014 06:50 AM, Adhemerval Zanella wrote:
> > Hi,
> > 
> > Following comments from my first patch to optimize single-thread internal
> > glibc locking/atomics [1], I have changed the implementation to use now
> > relaxed atomics instead.  Addresing the concerns raised in last discussion, 
> > the primitives are still signal-safe (although not thread-safe), so if future
> > malloc implementation is changed to be async-safe, it won't require to a
> > adjust powerpc atomics.
> > 
> > For catomic_and and catomic_or I follow the definition at 'include/atomic.h'
> > (which powerpc is currently using) and implemented the atomics with acquire
> > semantics.  The new implementation also is simpler.
> > 
> > On synthetic benchmarks it shows an improvement of 5-10% for malloc
> > calls and an performance increase of 7-8% in 483.xalancbmk from
> > speccpu2006 (number from an POWER8 machine).
> > 
> > Checked on powerpc64, powerpc32 and powerpc64le.
> 
> Wow, that's a lot of boiler-plate.
> 
> When development opens again, can we simplify all of these atomic operations by
> assuming compiler primitives?  That is, use the __atomic builtins for gcc 4.8
> and later, fall back to the __sync builtins for earlier gcc, and completely
> drop support for truly ancient compilers that support neither.

I definitely agree we should be moving away from the custom
implementation of the atomics.  I'm fine with having wrappers to enable
the custom stuff Joseph mentioned.

> As a bonus we'd get to unify the implementations across all of the targets.

And we should take that as an opportunity to unify towards the C11 model
and operations.  Not the same function names, but the same
functionality.  Including relaxed MO, relaxed MO but atomic loads/stores
instead of plain loads/stores if those synchronize, etc.

This has been on my list for a while, but I didn't get to it so far.