Hi!
We would like to open the discussion on SIMD-Accelerated CRC via
crc-fast for ext/hash.
RFC:
PR:
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.RFC:
PHP: rfc:crc-fast
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 hash: Add SHA-NI implementation of SHA-256 by TimWolla · Pull Request #15152 · php/php-src · GitHub 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 Tim!
Thanks for your feedback.
On 19.02.2026, at 09:20, Tim Düsterhus <tim@bastelstu.be> wrote:
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.
[…]
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.
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!
interesting proposal. Do you have benchmark that compares the rust implementation with this one crates.io: Rust Package Registry too ?
regards,
Mathieu Rochette
On Tuesday, February 17th, 2026 at 12:39, Michael Wallner <mike@php.net> wrote:
Hi!
We would like to open the discussion on SIMD-Accelerated CRC via
crc-fast for ext/hash.RFC:
PHP: rfc:crc-fastTL;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-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 policies/feature-proposals.rst at main · php/policies · GitHub). 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
On 24.02.2026, at 11:43, Mathieu Rochette <mathieu@rochette.cc> wrote:
interesting proposal. Do you have benchmark that compares the rust implementation with this one crates.io: Rust Package Registry too ?
No, sorry. The library only provides for 16/32/64 bit width CRCs.
Thanks,
Mike