i want BLAKE3 hash support in php,
some justifications can be found here https://bugs.php.net/bug.php?id=79492
primary reasons being that it's a "cryptographically secure hash",
predecessor BLAKE was nearly crowned "SHA3" (SHA3 finalist),
and it's very fast in software,
when i run it against php-src/ext/hash/bench.php , on a cpu without
the most beneficial instruction-set available, it was still over 4
times faster than sha3-224, outperforming even several
non-crypto-hashes, exact numbers here:
https://github.com/php/php-src/pull/6358#issuecomment-713506971 )
i have a PR here: https://github.com/php/php-src/pull/6358
initially had several issues, but i think most of them are resolved now,
- SSE/AVX optimizations are added for "gcc+(unix|windows)+x86_64" targets,
and i have asked the php-windows mailing list for help in adding
SSE/AVX optimizations to the MSVC builds,
but for the time being, MSVC builds are just using a portable generic
C implementation.
it would also be possible to add an optimized implementation for
ARM+Neon targets, i haven't looked into that at all.
- currently the code is rolling it's own cpu feature detection,
instead of asking Zend/zend_cpuinfo.c (specifically
ext/hash/blake3/blake3_dispatch.c ),
is that something that "must be fixed" before upstream merging can be
considered? or is it ok-ish?
- frankly, there's just *a lot* of code in there, is it possible that
it will be rejected just because "it's too much code" ? (there's a
reason there's so much code though, it contains cpu-specific
implementations for a lot of different environments, compilers, OS's,
and CPU's, from SSE2 to AVX512 to ARM+Neon, also a much smaller
implementation using just the "portable generic C implementation"
would be possible, at the cost of performance)
