From 4a5b8a5bee8bd90f52c725030730c60bbf79a437 Mon Sep 17 00:00:00 2001 From: Andy Polyakov Date: Mon, 25 Jul 2005 13:29:42 +0000 Subject: [PATCH] Commentary section update in sha512-x86_64.pl. --- crypto/sha/asm/sha512-x86_64.pl | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/crypto/sha/asm/sha512-x86_64.pl b/crypto/sha/asm/sha512-x86_64.pl index 28937de0fa..38157b610c 100755 --- a/crypto/sha/asm/sha512-x86_64.pl +++ b/crypto/sha/asm/sha512-x86_64.pl @@ -8,7 +8,8 @@ # # sha256/512_block procedure for x86_64. # -# 40% improvement over compiler-generated code on Opteron. No magical +# 40% improvement over compiler-generated code on Opteron. On EM64T +# sha256 was observed to run >80% faster and sha512 - >40%. No magical # tricks, just straight implementation... I really wonder why gcc # [being armed with inline assembler] fails to generate as fast code. # The only thing which is cool about this module is that it's very @@ -34,10 +35,10 @@ # # Special note on Intel EM64T. While Opteron CPU exhibits perfect # perfromance ratio of 1.5 between 64- and 32-bit flavors [see above], -# [currently available] EM64T CPUs apparently are far from it. 64-bit -# version, sha512_block, is hardly faster than 32-bit one. This is -# presumably because 64-bit shifts/rotates apparently are not atomic -# instructions, but implemented in microcode. +# [currently available] EM64T CPUs apparently are far from it. On the +# contrary, 64-bit version, sha512_block, is ~30% *slower* than 32-bit +# sha256_block:-( This is presumably because 64-bit shifts/rotates +# apparently are not atomic instructions, but implemented in microcode. $output=shift; open STDOUT,"| $^X ../perlasm/x86_64-xlate.pl $output"; -- 2.25.1