Re: Proposal for Updating CRC32C with AVX-512 Algorithm.

From: Andres Freund <andres(at)anarazel(dot)de>
To: John Naylor <johncnaylorls(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, "Shankaran, Akash" <akash(dot)shankaran(at)intel(dot)com>, "Devulapalli, Raghuveer" <raghuveer(dot)devulapalli(at)intel(dot)com>
Subject: Re: Proposal for Updating CRC32C with AVX-512 Algorithm.
Date: 2024-12-12 15:45:29
Message-ID: 5rnt26xcnd6flvnahyr37kozdiagfj5cczsmolu722ccfgeyy3@3yj5crjnf3o5
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2024-12-12 18:32:20 +0700, John Naylor wrote:
> I went and looked at the Chromium source, and found the following
> snippet that uses the same technique, but only requires 128-bit CLMUL
> and has a minimum input size of 64 bytes, rather than 256. This seems
> like it might be better suited for shorter inputs. Also seems much
> easier than trying to get the AVX-512 hippo to dance. It uses the IEEE
> polynomial, so would need new constants calculated for ours, but that
> had to be done for the shared patch, too.

Frankly, we should just move away from using CRCs. They're good for cases
where short runs of bit flips are much more likely than other kinds of errors
and where the amount of data covered by them has a low upper bound. That's not
at all the case for WAL records. It'd not matter too much if CRCs were cheap
to compute - but they aren't. We should instead move to some more generic
hashing algorithm, decent ones are much faster.

Greetings,

Andres

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2024-12-12 15:53:00 Re: .ready and .done files considered harmful
Previous Message Tom Lane 2024-12-12 15:35:15 Re: pg_createsubscriber TAP test wrapping makes command options hard to read.