Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112093 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 65386 invoked from network); 21 Oct 2020 20:17:10 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 21 Oct 2020 20:17:10 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D43AA18053D for ; Wed, 21 Oct 2020 12:34:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 21 Oct 2020 12:34:19 -0700 (PDT) Received: by mail-pf1-f180.google.com with SMTP id e10so2106633pfj.1 for ; Wed, 21 Oct 2020 12:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=uZ8U1v+swUcefCfsH0c7VhYosd+G59fgWAOPk1ACdRE=; b=hN5D39nUjgVk0tRW4w66n/KBnCh8QSqUfNH+PujrcsgKfEc+YttjNcAJ/GPreqyoWv Eb4oQf+eAi6A0/rjAliP+/RMDt0N6sZJE/ajR9f359yhQ00oxFeaj0l9f7pl8ZZo5XEW wyy8ExOdOJViHqLW+K+APxJNOcZUXLvV/fgIapFHGP2Iyh217Q6zD6Lw3srfqraS+jJE BZyVceUFoW+nHILFyw75R7pdCwoXT4LKQR61IONZz76QP2njTKpy2oUpkSBOE9sl2EZv abqGyevWxdv4vQFb0ev70wYjOjJqq4JpUikuoJswbeC8wjtryvNlG41Kp2YOfB+y2Rui tSLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uZ8U1v+swUcefCfsH0c7VhYosd+G59fgWAOPk1ACdRE=; b=Rlzje72mkOlb96jaZNjHdojF2xfkZJUi6hEYWFznFlTPnXBXXIg1t3v9S0/FdCc7gy Yr2GccSd8qfkrANHl3V3k5NHXU6TpxOcxAhz0WLKKn1UTDwWc12JWt7+/Bh1tSpXuImw TIcABdFVBVOBvY9K1jEd550ZnVDZTT0518yL3a7HltEflcgTk91qG8324BWa+8QiZWYX Q4M/6/gd/Wh1YRVGsd10Y2QXm44m1ldxyfJeT7xNN/NXmANDpLBT91sUM6Bd5mXFnbwA ff1bSqI2Ete4PBvJrT5aUp9P2AhejHNh582edJ6eX6Aqh+rRaLrlPDrCwd5+uhrjP1Ku II9w== X-Gm-Message-State: AOAM530MjO8VJCksZqYF7Q2tW146bzOgBvYtCVxwLEeEqPeJizbwurlj xMNeBFipwzbWHDTGIufV2XxE/M6dGjaJxL7P+yySWeouHcI= X-Google-Smtp-Source: ABdhPJxtvXUf8H8VSYuZcUsRuJQG2FzECI696o+Q7PokBijygEyU02bHMUlqpH1+EaRBaBMG5nCVzPz6hDfuPxf6W+k= X-Received: by 2002:a63:1f19:: with SMTP id f25mr4814373pgf.232.1603308856969; Wed, 21 Oct 2020 12:34:16 -0700 (PDT) MIME-Version: 1.0 Date: Wed, 21 Oct 2020 21:34:03 +0200 Message-ID: To: PHP internals Content-Type: text/plain; charset="UTF-8" Subject: hash BLAKE3 From: divinity76@gmail.com (Hans Henrik Bergan) 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)