| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | "Amonson, Paul D" <paul(dot)d(dot)amonson(at)intel(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, "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: Proposal for Updating CRC32C with AVX-512 Algorithm. |
| Date: | 2024-08-26 18:38:30 |
| Message-ID: | ZszLpuzAwILy1Qq3@nathan |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amonson, Paul D | 2024-08-26 18:44:55 | RE: Proposal for Updating CRC32C with AVX-512 Algorithm. |
| Previous Message | Masahiko Sawada | 2024-08-26 18:25:53 | Re: Fix memory counter update in reorderbuffer |