From: | "Amonson, Paul D" <paul(dot)d(dot)amonson(at)intel(dot)com> |
---|---|
To: | Nathan Bossart <nathandbossart(at)gmail(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-22 16:19:20 |
Message-ID: | BL1PR11MB5304837ABA2CC63CFE6380D0DC8F2@BL1PR11MB5304.namprd11.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Upthread [0], Andres suggested dispatching to a different implementation for
> compile-time-known small lengths. Have you looked into that? In your
> original post, you noted a 14% regression for records smaller than 256 bytes,
> which is not an uncommon case for Postgres. IMO we should try to mitigate
> that as much as possible.
So, without adding even more conditional tests (causing more latency), I can expose a new macro called COMP_CRC32C_SMALL that can be called from known locations where the size is known to be 20bytes or less (or any fixed size less than 256). Other than that, there is no method I know of to pre-decide calling a function based on input size. Is there any concrete thought on this?
Paul
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-08-22 16:20:24 | Re: Usage of ProcessConfigfile in SIGHUP_Handler |
Previous Message | Lakshmi Narayana Velayudam | 2024-08-22 16:00:05 | Re: Usage of ProcessConfigfile in SIGHUP_Handler |