Re: always use runtime checks for CRC-32C instructions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org, Xiang(dot)Gao(at)arm(dot)com
Subject: Re: always use runtime checks for CRC-32C instructions
Date: 2023-10-31 20:12:40
Message-ID: 2620794.1698783160@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Nathan Bossart <nathandbossart(at)gmail(dot)com> writes:
> Okay. With that in mind, I think the path forward for new instructions is
> as follows:

> * If the special CRC instructions can be used with the default compiler
> flags, we can only use newer instructions if they can also be used with
> the default compiler flags. (My M2 machine appears to add +crypto by
> default, so I bet your buildfarm animals would fall into this bucket.)
> * Otherwise, if the CRC instructions can be used with added flags (i.e.,
> the runtime check path), we can do a runtime check for the new
> instructions as well. (Most other buildfarm animals would fall into this
> bucket.)

This seems like a reasonable proposal.

> Any platform that can use the CRC instructions with default compiler flags
> but not the new instructions wouldn't be able to take advantage of the
> proposed optimization, but it also wouldn't be subject to the small
> performance regression.

Check. For now I think that's fine. If we get to a place where this
policy is really leaving a lot of performance on the table, we can
revisit it ... but that situation is hypothetical and may remain so.

(It's worth noting also that a package builder can move the goalposts
at will, since our idea of "default flags" is really whatever the user
says to use.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-10-31 20:38:17 Re: always use runtime checks for CRC-32C instructions
Previous Message Tristan Partin 2023-10-31 20:03:38 Re: Use thread-safe locale APIs