Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130457
Precedence: list
MIME-Version: 1.0
References: <CALJZF3jT2fwdP1Sg6uDn71hvJnTaHZqKrTqm1jQh2pNi-bpcnQ@mail.gmail.com>
In-Reply-To: <CALJZF3jT2fwdP1Sg6uDn71hvJnTaHZqKrTqm1jQh2pNi-bpcnQ@mail.gmail.com>
Date: Wed, 25 Mar 2026 15:01:47 -0500
Message-ID: <CAESVnVp83BsuWf2i+B7Lo3cNPrDQqirvqU=m35eeEvLD1xSsOQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] SIMD-Accelerated CRC via crc-fast
 for ext/hash
To: Michael Wallner <mike@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d9a358064ddebddf"
From: php@golemon.com (Sara Golemon)

--000000000000d9a358064ddebddf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 17, 2026 at 5:41=E2=80=AFAM Michael Wallner <mike@php.net> wrot=
e:
> 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
>

My initial reaction on seeing this RFC (just browsing wiki.php.net/rfc, not
from the email) was "Why give this a new name?"

Would it be too onerous to support transparently upgrading calls to
hash('crc32'), hash('crc32b'), and crc32() to just use the faster
implementation when available?  (P.S. - Luagh/Cry that this library has a
flag for our "quirk".) The build system define should provide all the
signal we need, but a cached CPU capabilities check could be added for
belts and suspenders.

Or is there a reason to doubt the reliability of the faster algorithms?  My
desire here is to make choosing the better option easier than choosing the
wrong one.  A developer who knows what they're doing can interrogate
hash_algos(), but that's harder to cache and misses some of the performance
boost in the happy path, and makes it worse in the sad path.

-Sara

--000000000000d9a358064ddebddf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Feb 17, 2026 at 5:41=E2=80=AFAM Michael Wallner &l=
t;<a href=3D"mailto:mike@php.net">mike@php.net</a>&gt; wrote:<br>&gt; We wo=
uld like to open the discussion on SIMD-Accelerated CRC via<br>&gt; crc-fas=
t for ext/hash.<br>&gt;<br>&gt; RFC:<br>&gt; <a href=3D"https://wiki.php.ne=
t/rfc/crc-fast">https://wiki.php.net/rfc/crc-fast</a><br>&gt;<br>&gt; PR:<b=
r>&gt; <a href=3D"https://github.com/php/php-src/pull/20513">https://github=
.com/php/php-src/pull/20513</a><br>&gt;<div><br></div><div>My initial react=
ion on seeing this RFC (just browsing <a href=3D"http://wiki.php.net/rfc">w=
iki.php.net/rfc</a>, not from the email) was &quot;Why give this a new name=
?&quot;<br><br>Would it be too onerous to support transparently upgrading c=
alls to hash(&#39;crc32&#39;), hash(&#39;crc32b&#39;), and crc32() to just =
use the faster implementation when available?=C2=A0 (P.S. - Luagh/Cry that =
this library has a flag for our &quot;quirk&quot;.) The build system define=
 should provide all the signal we need, but a cached CPU capabilities check=
 could be added for belts and suspenders.<br><br>Or is there a reason to do=
ubt the reliability of the faster algorithms?=C2=A0 My desire here is to ma=
ke choosing the better option easier than choosing the wrong one.=C2=A0 A d=
eveloper who knows what they&#39;re doing can interrogate hash_algos(), but=
 that&#39;s harder to cache and misses some of the performance boost in the=
 happy path, and makes it worse in the sad path.</div><div><br></div><div>-=
Sara<br><br><br></div></div>

--000000000000d9a358064ddebddf--