Обсуждение: [PATCH] CRC32C optimizations using SVE2 on ARM.

These buffer sizes are particularly relevant for PostgreSQL workloads:

void pg_comp_crc32c_choose_armv8(void)

{

    if (pg_cpu_has_sve2())

        pg_comp_crc32c_armv8 = pg_comp_crc32c_armv8_sve2;

    else if (pg_cpu_has_crypto())

        pg_comp_crc32c_armv8 = pg_comp_crc32c_armv8_crypto;

    else

        pg_comp_crc32c_armv8 = pg_comp_crc32c_sb8; // scalar fallback

}

Thanks,
Susmitha Devanga.

From: John Naylor <johncnaylorls@gmail.com>
Sent: Friday, December 19, 2025 08:27
To: Susmitha, Devanga <Devanga.Susmitha@fujitsu.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>; Hajela, Ragesh <Ragesh.Hajela@fujitsu.com>; Bhattacharya, Chiranmoy <Chiranmoy.Bhattacharya@fujitsu.com>
Subject: Re: [PATCH] CRC32C optimizations using SVE2 on ARM.

On Fri, Dec 19, 2025 at 4:20 AM Devanga.Susmitha@fujitsu.com
<Devanga.Susmitha@fujitsu.com> wrote:
> For architecture-specific functions, we use pg_attribute_target("arch=armv9-a+sve2-aes")

There was already a proposal to use armv8-a+crypto, which is more
widely available and works on smaller inputs. Perhaps you'd be
interested in reviewing and testing?

https://www.postgresql.org/message-id/CANWCAZaKhE%2BRD5KKouUFoxx1EbUNrNhcduM1VQ%3DDkSDadNEFng%40mail.gmail.com

> to ensure precise compilation control without modifying global CFLAGS, enabling a clean integration within PostgreSQL’s build system.

I think the reason we continue to use CFLAGS here was that clang
support for target attributes on Arm is fairly recent. It's probably
too soon to reconsider that.

--
John Naylor
Amazon Web Services

On Mon, Jan 5, 2026 at 4:02 PM Devanga.Susmitha@fujitsu.com <Devanga.Susmitha@fujitsu.com> wrote:
>
> >There was already a proposal to use armv8-a+crypto, which is more
> widely available and works on smaller inputs.
>
> Our implementation with SVE2 is able to gain better performance than
> https://www.postgresql.org/message-id/CANWCAZaKhE%2BRD5KKouUFoxx1EbUNrNhcduM1VQ%3DDkSDadNEFng%40mail.gmail.com
>
> I've benchmarked our SVE2 implementation against armv8-a+crypto, and the results show substantial improvements.

Thanks for testing! For future reference, please don't top post. We prefer to reply in-line to relevant points.

> These buffer sizes are particularly relevant for PostgreSQL workloads:
>
> 8KB: Default page size (28.8% faster checksumming)
> 4KB: Alternative page size configuration (36.1% faster)

We don't use CRC for page checksums. Did you mean FPI in WAL?

> 512B-2KB: Typical WAL record sizes (32-39% faster)

That seems on the high end, but your mileage may vary. Even if it were typical, the difference isn't that impressive, given that the patch seems to use double the number of (twice as wide?) accumulators. In any case, I suspect going from (say) 3x to 4x won't make much difference in profiles for those workloads, aside from having less portability. Plus, it seems more widely useful to allow a cutoff at 64 bytes, rather than 128.

> While armv8-a+crypto has broader current deployment, SVE2 is already available in production cloud infrastructure: AWS Graviton 4, Ampere AmpereOne, and NVIDIA Grace (all released 2023). As ARMv9 adoption continues, these gains become increasingly relevant.

That's pretty recent.

> Rather than choosing one approach over the other, perhaps we could implement both with runtime CPU detection?

That's bad for maintainability.

The broader point is I've already found something that seems good enough (and can be configured differently if necessary), portable enough, and is already used for our x86 vectorized implementation. I just wasn't going to make it a priority until someone showed up with enough interest to test and review it.

--
John Naylor
Amazon Web Services