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

Nathan Bossart <nathandbossart@gmail.com>

From: Nathan Bossart <nathandbossart@gmail.com>

To: "Amonson, Paul D" <paul.d.amonson@intel.com>

Cc: Bruce Momjian <bruce@momjian.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Andres Freund <andres@anarazel.de>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, "Shankaran, Akash" <akash.shankaran@intel.com>

Date: 2024-08-26T18:38:30Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Compute CRC32C using AVX-512 instructions where available
- 3c6e8c123896 18.0 landed

On Mon, Aug 26, 2024 at 05:09:35PM +0000, Amonson, Paul D wrote:
> Ok I added a patch that exposed a new macro CRC32C_COMP_SMALL for
> targeted fixed size < 256 use cases in Postgres. As for mitigating the
> regression in general, I have not been able to work up a fallback (i.e.
> <256 bytes) that doesn't involve runtime checks which cause latency. I
> also attempted to change the AVX512 fallback from the current algorithm
> in the avx512 implementation to the SSE original implementation, but I am
> not seeing any real difference for this use case in performance.

I'm curious about where exactly the regression is coming from.  Is it
possible that your build for the SSE 4.2 tests was using it
unconditionally, i.e., optimizing away the function pointer?

-- 
nathan