Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130094
Precedence: list
MIME-Version: 1.0
Date: Thu, 19 Feb 2026 09:20:30 +0100
To: Michael Wallner <mike@php.net>
Cc: PHP Internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [Discussion] SIMD-Accelerated CRC via crc-fast
 for ext/hash
In-Reply-To: <CALJZF3jT2fwdP1Sg6uDn71hvJnTaHZqKrTqm1jQh2pNi-bpcnQ@mail.gmail.com>
References: <CALJZF3jT2fwdP1Sg6uDn71hvJnTaHZqKrTqm1jQh2pNi-bpcnQ@mail.gmail.com>
Message-ID: <e70a4db113cfcd215e7bb0692909f6ba@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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