From: Nathan Bossart <nathandbossart@gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Bastien Roucariès <rouca@debian.org>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: Detection of hadware feature => please do not use signal
Date: Thu, 7 Nov 2024 09:28:44 -0600
Message-ID: <ZyzcrD2GsvIFrDdO@nathan> (raw)
In-Reply-To: <CA+hUKGKvZ7eyMOCt-k=Ezuvn6GLR9fFSLRFYA666OFMnK2kgTQ@mail.gmail.com>
References: <4496616.iHFcN1HehY@portable-bastien>
<af84e934-4e9c-4380-95ee-8921dab1254b@iki.fi>
<1156374.1730396928@sss.pgh.pa.us>
<7ec1c65c-1a28-49a7-af43-f77c260a3df6@iki.fi>
<1292593.1730399134@sss.pgh.pa.us>
<CA+hUKGLRXq0-s0n2=dy_A5iY-Omg628osyJEJMjPQ=6m566UgA@mail.gmail.com>
<1624905.1730436275@sss.pgh.pa.us>
<1637254.1730441792@sss.pgh.pa.us>
<CA+hUKGKvZ7eyMOCt-k=Ezuvn6GLR9fFSLRFYA666OFMnK2kgTQ@mail.gmail.com>
On Sat, Nov 02, 2024 at 06:11:33PM +1300, Thomas Munro wrote:
> On Fri, Nov 1, 2024 at 7:16 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Actually, after chewing on that second point awhile longer,
>> how about this modest proposal:
>>
>> * Drop all code for run-time determination of ARM CRC support.
>> Assume it's there unless user builds with a -march option that
>> says it definitely isn't.
>
> For CRC32, that would work (and already does via configure tests) for
> macOS (I'd forgotten about that in my earlier message, Macs never even
> compile the CRC32 "choose" code because the system compiler targets M1
> by default), recent RHEL (see below), and presumably others, but it
> would penalise Debian, FreeBSD (using the standard binary package
> repo) and others if we didn't have the runtime check due to their
> conservative choice of baseline arch (as Bastien just said about
> Debian in a crossed email). I've been wondering about what to do
> about all this for a while... There are also other features we aren't
> using yet, but should, or single instructions that we are calling
> through function pointers, preventing automatic vectorisation etc.
One small improvement in this area that I'm working on (and about to commit
for the AVX-512 stuff) is using __attribute__((target(...))) instead of
special -march options for specific files [0]. Among other things, this
simplifies the configure checks and eliminates the need to put chunks of
code in separate files. However, I found that until recently, it wasn't
possible to include arm_acle.h without the -march flag [1], which means we
likely won't be able to make the switch for the ARM CRC stuff for a few
more years.
More to the point, until the baseline moves, I think we'll end up adding
checks in header files so that we only take the function pointer overhead
when it's likely to be worth it (e.g., pg_popcount() in pg_bitutils.h). It
might be worth doing that for the CRC-32C code, too, since we are still
quite reliant on the runtime check.
[0] https://commitfest.postgresql.org/50/5305/
[1] https://postgr.es/m/ZwXsE0KG_wh6_heU%40nathan
--
nathan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: nathandbossart@gmail.com, thomas.munro@gmail.com, tgl@sss.pgh.pa.us, hlinnaka@iki.fi, rouca@debian.org, pgsql-bugs@lists.postgresql.org
Subject: Re: Detection of hadware feature => please do not use signal
In-Reply-To: <ZyzcrD2GsvIFrDdO@nathan>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox