Re: Proposal for Updating CRC32C with AVX-512 Algorithm. - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Proposal for Updating CRC32C with AVX-512 Algorithm.
Date
Msg-id ZszYPB3KxKsBexga@nathan
Whole thread Raw
In response to RE: Proposal for Updating CRC32C with AVX-512 Algorithm.  ("Amonson, Paul D" <paul.d.amonson@intel.com>)
List pgsql-hackers
On Mon, Aug 26, 2024 at 07:15:47PM +0000, Amonson, Paul D wrote:
>> +#define COMP_CRC32C_SMALL(crc, data, len) \
>> +    ((crc) = pg_comp_crc32c_sse42((crc), (data), (len)))
>> 
>> My interpretation of Andres's upthread suggestion is that we'd add the length
>> check within the macro instead of introducing a separate one.  We'd expect
>> the compiler to optimize out comparisons for small lengths known at compile
>> time and always call the existing implementation (which may still involve a
>> function pointer in most cases).
> 
> How does the m4/compiler know the difference between a const "len" and a
> dynamic "len"? I already when the code and changed constant sizes
> (structure sizes) to the new macro. Can you give an example of how this
> could work?

Things like sizeof() and offsetof() are known at compile time, so the
compiler will recognize when a condition is always true or false and
optimize it out accordingly.  In cases where the value cannot be known at
compile time, checking the length in the macro and dispatching to a
different implementation may still be advantageous, especially when the
different implementation doesn't involve function pointers.

-- 
nathan



pgsql-hackers by date:

Previous
From: John H
Date:
Subject: Re: Allow logical failover slots to wait on synchronous replication
Next
From: Robert Haas
Date:
Subject: Re: allowing extensions to control planner behavior