Re: Remove last traces of HPPA support

Hi,

On 2023-10-20 17:46:59 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2023-10-20 15:59:42 -0400, Tom Lane wrote:
> >> Hmm, are you saying there's more of port/atomics/ that could be
> >> removed? What exactly?
>
> > I was thinking we could remove the whole fallback path for atomic operations,
> > but it's a bit less, because we likely don't want to mandate support for 64bit
> > atomics yet.
>
> Yeah. That'd be tantamount to desupporting 32-bit arches altogether,
> I think. I'm not ready to go there yet.

It shouldn't be tantamount to that - many 32bit archs support 64bit atomic
operations. E.g. x86 supported it since the 586 (in 1993). However, arm only
addded them to 32 bit, in an extension, comparatively recently...

> > That'd still allow removing more than half of
> > src/include/port/atomics/fallback.h and src/backend/port/atomics.c - and more
> > if we finally decided to require a spinlock implementation.
>
> In the wake of 1c72d82c2, it seems likely that requiring some kind of
> spinlock implementation is not such a big lift. Certainly, a machine
> without that hasn't been a fit target for production in a very long
> time, so maybe we should just drop that semaphore-based emulation.

Yep. And the performance drop due to not having spinlock is also getting worse
over time, with CPU bound workloads having become a lot more common due to
larger amounts of memory and much much faster IO.

> >> Do we really want to assume that all future architectures will have atomic
> >> operations?
>
> > Yes. Outside of the tiny microcontrollers, which obviously won't run postgres,
> > I cannot see any future architecture not having support for atomic operations.
>
> I'd like to refine what that means a bit more. Are we assuming that a
> machine providing any of the gcc atomic intrinsics (of a given width) will
> provide all of them? Or is there a specific subset that we can emulate the
> rest on top of?

Right now we don't require that. As long as we know how to do atomic compare
exchange, we backfill all other atomic operations using compare-exchange -
albeit less efficiently (there's no retries for atomic-add when implemented
directly, but there are retries when using cmpxchg, the difference can be
significant under contention).

Practically speaking I think it's quite unlikely that a compiler + arch
combination will have only some intrinsics of some width - I think all
compilers have infrastructure to fall back to compare-exchange when there's no
dedicated atomic operation for some intrinsic.

Greetings,

Andres Freund