Re: [RFC] [Discussion] SIMD-Accelerated CRC via crc-fast for ext/hash
| From: | Michael Wallner | Date: | Mon, 23 Feb 2026 21:49:45 +0000 |
| Subject: | Re: [RFC] [Discussion] SIMD-Accelerated CRC via crc-fast for ext/hash | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-130143@lists.php.net to get a copy of this message | ||
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