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

From: 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

« previous php.internals (#130143) next »