Hi!
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
TL;DR:
Add --with-crc-fast configure option to link ext/hash to crc-fast
rust library and provide HW accelerated crc32 and crc64 algorithms.
--
Regards,
Mike
Hi
Am 2026-02-17 12:38, schrieb Michael Wallner:
We would like to open the discussion on SIMD-Accelerated CRC via
crc-fast for ext/hash.
Thank you. I've taken a look at your RFC and from what I see it's
effectively two different proposals:
- 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.
- 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 Tim!
Thanks for your feedback.
Thank you. I've taken a look at your RFC and from what I see it's effectively two different proposals:
- Make CRC calculations go fast with an optional external library.
[…]- 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.
Sorry for the confusion. I updated the relevant parts of the RFC to mention that non-HW accelerated CRC-64 implementations would always be available.
I’d prefer not to split this up, unless there’s strong demand for that in further discussion.
Thanks,
Mike
Hi
Am 2026-02-23 22:49, schrieb Michael Wallner:
I’d prefer not to split this up, unless there’s strong demand for that
in further discussion.
It definitely is two different proposals, so while they may be combined
into a single RFC document and discussion, it must at least be two
separate primary votes (see
https://github.com/php/policies/blob/main/feature-proposals.rst#required-majority).
I'm also noting that the current voting widget still contains the
$feature placeholder.
I also consider it important that each of the proposals gets the same
treatment with regard to visibility in the RFC text. Currently the RFC’s
focus is the introduction of the crc-fast library, while the new
algorithms only get a “passing mention”. However as I mentioned before,
the latter is the more significant change from a PHP developer’s PoV.
To give a specific example from the RFC (Highlighting original):
When --with-crc-fast is not specified or libcrc_fast is not installed,
PHP builds and behaves exactly as it does today with the addition of
the new CRC-64 algorithms implemented without hardware acceleration.
The “exactly as it does today” together with the “When enabled, the
following changes take effect:” introduction of the section, still
heavily implies that the new algorithms are dependent on the library
being used.
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
Hi!
We would like to open the discussion on SIMD-Accelerated CRC via
crc-fast for ext/hash.
TL;DR:
Add--with-crc-fastconfigure option to link ext/hash to crc-fast
rust library and provide HW accelerated crc32 and crc64 algorithms.
--
Regards,
Mike
interesting proposal. Do you have benchmark that compares the rust implementation with this one https://crates.io/crates/crc24-openpgp-fast too ?
No, sorry. The library only provides for 16/32/64 bit width CRCs.
Thanks,
Mike
We would like to open the discussion on SIMD-Accelerated CRC via
crc-fast for ext/hash.
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