Horton

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

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

View thread
From: "Amonson, Paul D" <paul.d.amonson@intel.com>
To: Nathan Bossart <nathandbossart@gmail.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-26T19:15:47Z
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 →

  1. Compute CRC32C using AVX-512 instructions where available

> IMHO that would be useful to establish the current state of the patch set from
> a performance standpoint, especially since you've added code intended to
> mitigate the regression.

Ok.

> +#define COMP_CRC32C_SMALL(crc, data, len) \
> +	((crc) = pg_comp_crc32c_sse42((crc), (data), (len)))
> 
> My interpretation of Andres's upthread suggestion is that we'd add the length
> check within the macro instead of introducing a separate one.  We'd expect
> the compiler to optimize out comparisons for small lengths known at compile
> time and always call the existing implementation (which may still involve a
> function pointer in most cases).

How does the m4/compiler know the difference between a const "len" and a dynamic "len"? I already when the code and changed constant sizes (structure sizes) to the new macro. Can you give an example of how this could work?

Paul