[RFC] [Discussion] SIMD-Accelerated CRC via crc-fast for ext/hash

Hi Am 2026-02-17 12:38, schrieb Michael Wallner:

Thank you. I've taken a look at your RFC and from what I see it's effectively two different proposals: 1. Make CRC calculations go fast with an optional external library. For this I'm not sure if an RFC is actually required. If it's completely optional and “transparent” to a developer using PHP, then the only concern is possible maintenance effort by the core team. This is usually something the core developers just informally agree on amongst themselves, since the voter base doesn't really have the necessary insights there. See https://github.com/php/php-src/pull/15152 for a previous PR of mine adding SHA-NI support for SHA-256. It didn't go through an RFC either. 2. Add various CRC-64 variants. Adding new variants makes sense to me, particularly since the API of ext/hash is specifically designed to be extensible in this way and since there is a clear use case with the S3 SDK. But it makes sense to do this as an RFC to figure out the details, particularly naming. One thing I'm concerned about here is that the RFC states that the new variants are dependent on the external library to be available. ext/hash is one of the few extensions that folks can rely on always being available, which is very useful. I believe we should strive to not make its feature set dependent on build time choices of PHP, because that means that frameworks, libraries (e.g. the AWS SDK) or “off-the-shelf” applications will never be able to rely on the algorithms being available, especially if it relies on a specialized library being available, which will hurt adoption and increases ecosystem fragmentation. I believe it is important to always provide a baseline implementation written in pure C for this reason. I suspect it shouldn't be too complicated to add this, since the various CRCs are generally very simple algorithms. Best regards Tim Düsterhus

Hi! interesting proposal. Do you have benchmark that compares the rust implementation with this one https://crates.io/crates/crc24-openpgp-fast too ? regards, Mathieu Rochette On Tuesday, February 17th, 2026 at 12:39, Michael Wallner <mike@php.net> wrote:

On Tue, Feb 17, 2026 at 5:41 AM Michael Wallner <mike@php.net> wrote:

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