Re: Improve CRC32C performance on SSE4.2
John Naylor <johncnaylorls@gmail.com>
From: John Naylor <johncnaylorls@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: "Devulapalli, Raghuveer" <raghuveer.devulapalli@intel.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, "Shankaran, Akash" <akash.shankaran@intel.com>
Date: 2025-03-06T11:45:40Z
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
- v12-0006-Only-inline-for-constant-input-partial-revert.patch (text/x-patch) patch v12-0006
- v12-0004-Improve-CRC32C-performance-on-x86_64.patch (text/x-patch) patch v12-0004
- v12-0003-Inline-CRC-computation-for-small-fixed-length-in.patch (text/x-patch) patch v12-0003
- v12-0005-Use-runtime-check-even-when-we-have-SSE-4.2-at-c.patch (text/x-patch) patch v12-0005
- v12-0002-Attempt-to-make-benchmark-more-sensitive-to-late.patch (text/x-patch) patch v12-0002
- v12-0001-Add-a-Postgres-SQL-function-for-crc32c-benchmark.patch (text/x-patch) patch v12-0001
On Wed, Mar 5, 2025 at 10:52 PM Nathan Bossart <nathandbossart@gmail.com> wrote: > > On Wed, Mar 05, 2025 at 08:51:21AM +0700, John Naylor wrote: > > That was my hunch too, but I wanted to be more sure, so I modified the > > benchmark so it doesn't know the address of the next calculation until > > it finishes the last calculation so we can hopefully see the latency > > caused by indirection. It also does an additional calculation on > > constant 20 bytes, like the WAL header. I also tweaked the length each > > iteration so the branch predictor maybe has a harder time predicting > > the constant 20 input. And to make it more challenging, I removed the > > part that inlined all small inputs, so it inlines only constant > > inputs: > > Would you mind sharing this test? The test script is the same as here, except I only ran small lengths: https://www.postgresql.org/message-id/CANWCAZahvhE-%2BhtZiUyzPiS5e45ukx5877mD-dHr-KSX6LcdjQ%40mail.gmail.com ...but I must have forgotten to attach the slightly tweaked patch set, which I've done now. 0002 modifies the 0001 test module and 0006 reverts inlining non-constant input from 0005, just to see if I could find a regression from indirection, which I didn't. If we don't need it, it'd better to avoid inlining loops to keep from bloating the binary. > It sounds like you are running a > workload with a mix of constant/inlined calls and function pointer calls to > simulate typical usage for WAL, but I'm not 100% sure I'm understanding you > correctly. Exactly. -- John Naylor Amazon Web Services