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:
https://wiki.php.net/rfc/crc-fast

PR:
https://github.com/php/php-src/pull/20513

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

Reply via email to