RE: Improve CRC32C performance on SSE4.2

From: "Devulapalli, Raghuveer" <raghuveer(dot)devulapalli(at)intel(dot)com>
To: John Naylor <johncnaylorls(at)gmail(dot)com>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Shankaran, Akash" <akash(dot)shankaran(at)intel(dot)com>
Subject: RE: Improve CRC32C performance on SSE4.2
Date: 2025-02-26 00:20:51
Message-ID: PH8PR11MB82867CEDDECB60530DB96BD1FBC22@PH8PR11MB8286.namprd11.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sadeq Dousti 2025-02-26 00:27:23 Re: psql \dh: List High-Level (Root) Tables and Indexes
Previous Message Masahiko Sawada 2025-02-26 00:20:42 Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation