I missed this post - thanks Florian!
Indeed, SHA-1 is deprecated at least as far as being a cryptographic
algorithm is concerned, but it still has some uses in data verification
in a similar vein to MD5. I know git uses it internally so server
branches can't be corrupted.
I have probably spent too much time on SHA-1 already - its awkward size
of 160 bits has always irked me... not a clean power of two!
Speaking of the Intel SHA instructions, can I introduce a merge request
that adds "CPUX86_HAS_SHA" as a feature flag? I know to add it for
"cpu_zen" and later, but I'm not sure what the equivalent Intel
processor is... is "cpu_core_avx2" okay or does there need to be a new one?
Kit
On 15/09/2023 22:48, Florian Klämpfl via fpc-devel wrote:
Am 16.09.23 um 15:13 schrieb J. Gareth Moreton via fpc-devel:
Hi everyone,
So this past week I've been building on Rika's work by adding an
assembly version of SHA-1 for x86_64 to complement Rika's i386
version. So far I've successfully made a version that runs twice as
fast as the Pascal code. I hoped to go even faster by making use of
the SSE2 instruction set, but currently the end result is slower even
though computing the common parts of 4 rounds simultaneously should
be much faster. This occurs even when I forgo writing to the stack
and keep pretty much all of the state within registers. Preliminary
investigation suggests that the slowdown comes from using MOVD/Q to
transfer data between the XMM registers and general-purpose
registers, since they are different parts of the CPU. I'm still
amazed it causes this much latency though.
I'll keep investigating and seeing if I can squeeze out more
performance, but otherwise I may just have to fall back on a
non-SIMD-optimised implementation.
As SHA-1 is basically deprecated and not recommended to be used
anymore, I wouldn't spend too much into this. Besides this, for SHA-1
and SHA-256, it might be even more useful to use the SHA CPU
extensions if available. While they are only introduced in Ice Lake
and Zen, they will get more and more available in the future.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
