Re: Atomics hardware support table & supported architectures

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jun 23, 2014 at 11:16 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> Since fetch-and-add is trivially implemented using CAS, there's not much
>> need to distinguish between CAS and CAS + fetch_and_add. From my POV the
>> restriction to just CAS/fetch_and_add isn't actually buying much. Pretty
>> much all platforms but older gcc ones have atomic intrinsics since
>> forever. Once you've dug up the documentation for one operation not
>> adding two more or so doesn't save much.

> Again, the concern that was expressed at the developer's meeting was
> that the performance characteristics of the CAS loop might be
> significantly different from a native atomic op as to cause us
> heartburn. I think that's a valid concern... but if everything in
> common use has both CAS and fetch-and-add, then I think there's
> probably no issue here.

What I want to know is whether we are going to agree that the set of
atomics is going to be CAS plus fetch_and_add plus *nothing else*.

Andres seems to envision that those will be a minimal set and then
we'll freely use any other atomic op that seems handy as long as we can
provide a fallback implementation of it. I agree with Robert that
keeping track of the actual cross-platform performance characteristics
of such code would be a nightmare.

What I want to see is a list of atomic ops that is short enough that
we can agree we do not care about PG performance on any platform that
hasn't got (fast versions of) all of them. Then we will code and
optimize on the basis of having all those ops and no others. We can
offer fallback implementations of those ops so that older platforms
aren't entirely dead in the water, but they will not be the focus
of any performance testing.

regards, tom lane