RE: Improve CRC32C performance on SSE4.2

Devulapalli, Raghuveer <raghuveer.devulapalli@intel.com>

From: "Devulapalli, Raghuveer" <raghuveer.devulapalli@intel.com>

To: John Naylor <johncnaylorls@gmail.com>

Cc: Nathan Bossart <nathandbossart@gmail.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, "Shankaran, Akash" <akash.shankaran@intel.com>

Date: 2025-02-26T00:20:51Z

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 →

Include _mm512_zextsi128_si512() in AVX-512 configure probes.
- ccd5bc93fdfe 18.0 landed
Properly fix AVX-512 CRC calculation bug
- 43da394304fb 18.0 landed
Workaround code generation bug in clang
- f83f14881c7a 18.0 landed
Compute CRC32C using AVX-512 instructions where available
- 3c6e8c123896 18.0 landed
Inline CRC computation for small fixed-length input on x86
- e2809e3a1015 18.0 landed
Be more paranoid in configure's checks for CRC and POPCNT intrinsics.
- fdb5dd6331e3 18.0 cited

Attachments

v9-0001-Dispatch-CRC-computation-by-branching-rather-than.patch (application/octet-stream) patch v9-0001
v9-0002-Rename-CRC-choose-files-to-cpucap-files.patch (application/octet-stream) patch v9-0002
v9-0003-Add-a-Postgres-SQL-function-for-crc32c-benchmarki.patch (application/octet-stream) patch v9-0003
v9-0004-Improve-CRC32C-performance-on-x86_64.patch (application/octet-stream) patch v9-0004
v9-0005-Move-all-cpuid-checks-to-one-location.patch (application/octet-stream) patch v9-0005

> I agree it would be preferable to make a centralized check work.

Here is my first stab at it. v9 is same as v8 + a commit to move all cpuid checks into one single place including the AVX512 popcount code. Any new feature that requires CPUID information can access that information with pg_cpu_have[FEATURE] defined in pg_cpucap.h and initialized in pg_cpucap.c. v8 also had a typo in configure files which caused a build failure. Its fixed in v9.

Pretty sure the ARM code paths need some correction. Let me know what you think.
 
> Correct me if I'm misunderstanding, but this sounds like in every frontend
> program we'd need to know what the first call was, which seems less
> maintainable than just initializing at the start of every frontend program.

No, sorry for the confusion but that is not what I meant. Lets ignore the attribute constructor for now. We can probably revisit this at a later point.

Raghuveer