Re: [RFC] [Discussion] SIMD-Accelerated CRC via crc-fast for ext/hash
| From: | Sara Golemon | Date: | Wed, 25 Mar 2026 20:01:47 +0000 |
| Subject: | Re: [RFC] [Discussion] SIMD-Accelerated CRC via crc-fast for ext/hash | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-130457@lists.php.net to get a copy of this message | ||
On Tue, Feb 17, 2026 at 5:41 AM Michael Wallner <mike@php.net> wrote:
> We would like to open the discussion on SIMD-Accelerated CRC via
> crc-fast for ext/hash.
>
> RFC:
> https://wiki.php.net/rfc/crc-fast
>
> PR:
> https://github.com/php/php-src/pull/20513
>
My initial reaction on seeing this RFC (just browsing wiki.php.net/rfc, not
from the email) was "Why give this a new name?"
Would it be too onerous to support transparently upgrading calls to
hash('crc32'), hash('crc32b'), and crc32() to just use the faster
implementation when available? (P.S. - Luagh/Cry that this library has a
flag for our "quirk".) The build system define should provide all the
signal we need, but a cached CPU capabilities check could be added for
belts and suspenders.
Or is there a reason to doubt the reliability of the faster algorithms? My
desire here is to make choosing the better option easier than choosing the
wrong one. A developer who knows what they're doing can interrogate
hash_algos(), but that's harder to cache and misses some of the performance
boost in the happy path, and makes it worse in the sad path.
-Sara