Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130143
Content-Type: text/plain;
	charset=utf-8
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
Subject: Re: [PHP-DEV] [RFC] [Discussion] SIMD-Accelerated CRC via crc-fast
 for ext/hash
In-Reply-To: <e70a4db113cfcd215e7bb0692909f6ba@bastelstu.be>
Date: Mon, 23 Feb 2026 22:49:45 +0100
Cc: Michael Wallner <mike@php.net>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <522BCAA7-590D-4268-8F8A-4D7B95C71EE5@gmail.com>
References: <CALJZF3jT2fwdP1Sg6uDn71hvJnTaHZqKrTqm1jQh2pNi-bpcnQ@mail.gmail.com>
 <e70a4db113cfcd215e7bb0692909f6ba@bastelstu.be>
To: =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
From: mike.php.net@gmail.com (Michael Wallner)

Hi Tim!

Thanks for your feedback.

> On 19.02.2026, at 09:20, Tim D=C3=BCsterhus <tim@bastelstu.be> wrote:
>=20
>=20
> Thank you. I've taken a look at your RFC and from what I see it's =
effectively two different proposals:
>=20
> 1. Make CRC calculations go fast with an optional external library.
[=E2=80=A6]
> 2. Add various CRC-64 variants.
>=20
> 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.
>=20
> 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 =
=E2=80=9Coff-the-shelf=E2=80=9D 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.
>=20
> 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=E2=80=99d prefer not to split this up, unless there=E2=80=99s strong =
demand for that in further discussion.

Thanks,
Mike