Re: Is *fast* 32-bit support still important?

On Tue, Jul 30, 2024, at 09:25, Heikki Linnakangas wrote:
> On 29/07/2024 23:40, Joel Jacobson wrote:
>> To me, it's non-obvious whether introducing `#if SIZEOF_DATUM < 8` with
>> separate 32-bit and 64-bit code paths is worthwhile to maintain performance
>> for both.
>>
>> Knowing more about $subject can hopefully help us reason about how much
>> additional code complication is justifiable for *fast* 32-bit support.
>
> IMO I don't think it's worth adding extra code for fast 32-bit support
> anymore. However, I'd still be wary of *regressing* performance on
> 32-bit systems.
>
> So if you're adding a new fast path to a function, it's OK to make it
> 64-bit only, and fall back to the old slower code on 32-bit systems. But
> -1 on *removing* existing 32-bit fast path code, or rewriting things in
> a way that makes an existing function significantly slower than before
> on 32-bit systems.
>
> This isn't black or white though. It depends on how big a gain or
> regression we're talking about, and how complex the extra code would be.

Thanks for input.

I still haven't got any reports from real users of 32-bit PostgreSQL,
so my comments below are based on the assumption that such users exist
and have high performance needs.

I agree that it's not a black or white decision since quantifying complexity
is inherently challenging.

However, perhaps it would be possible to say something about
lower and upper bounds on 32-bit slowdown?

- Below a certain percentage slowdown,
extra 32-bit code optimization is definitively unnecessary.

- Above a certain percentage slowdown,
extra 32-bit code optimization is definitively necessary.

In the range between these bounds, I guess the decision should depend on
the specific added code complexity required?

It's also the question what percentage we're reasoning about here.
Is it the time spent in the function, or is it the total execution time?

/Joel