Re: Changing default -march landscape

On 13.06.24 04:00, Nathan Bossart wrote:
> That's true, but my point is that as soon as we start avoiding function
> pointers more commonly, it becomes difficult to justify adding them back in
> order to support new instruction sets.  Should we just compile in the SSE
> 4.2 version, or should we take a chance on AVX-512 with the function
> pointer?
> 
>>> The idea that's been floating around recently is to build a bunch of
>>> different versions of Postgres and to choose one on startup based on what
>>> the CPU supports.  That seems like quite a lot of work, and it'll increase
>>> the size of the builds quite a bit, but it at least doesn't have the
>>> aforementioned problem.
>>
>> I guess another idea would be for the PGDG packagers or someone else
>> interested in performance to create repos with binaries built for
>> these microarch levels and users can research what they need.  The new
>> -v2 etc levels are a lot more practical than the microarch names and
>> individual features...
> 
> Heartily agreed.

One thing that is perhaps not clear (to me?) is how much this matters 
and how much of it matters.  Obviously, we know that it matters some, 
otherwise we'd not be working on it.  But does it, like, matter only 
with checksums, or with thousands of partitions, or with many CPUs, or 
certain types of indexes, etc.?

If we're going to, say, create some recommendations for packagers around 
this, how are they supposed to determine the tradeoffs?  It might be 
easy for a packager to set some slightly-higher -march flag that is in 
line with their distro's policies, but it would probably be a lot more 
work to create separate binaries or a separate repository for, say, 
moving from SSE-something to AVX-something.  And how are they supposed 
to decide that, and how are they supposed to communicate that to their 
users?  (And how can we get different packagers to make somewhat 
consistent decisions around this?)

We have in a somewhat similar case quite clearly documented that without 
native spinlock support everything will be terrible.  And there is 
probably some information out there that without certain CPU support 
checksum performance will be terrible.  But beyond that we probably 
don't have much.