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) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
