Hi,
Pavel Semjanov wrote:
As for Sandy Bridge. I don't know... I could observe nominal variations,
2-3%, on my machine, but nothing close to 10%, so this is odd... If you
have energy, test with varying stack seed(*)...
It was my error, because I measured it in special application. It
doesn't know about OPENSSL_ia32cap_P and goes on non-shrd path. The
right numbers are 1005 for small loop and 971 for unrolled one. 971 is
the best value I've ever seen! Great work!
Come on, apart from your Sandy Bridge result for 1.8, it's virtually
equivalent. Nominal difference can be explained by environmental
factors, and if not, it's really low price to pay for >40% improvement
on Atom. Besides, it's actually "slow" architectures that need
optimization more :-)
Now I agree ;) 1.8 version is "best-balanced" for all architectures.
I'm not sure I agree: I've grabbed the 1.8 version and rebuilt openssl
1.0.1c and tested it on an i5 and a Core 2 Duo; performance is better
than the non-patched version but it is WORSE compared to the original
version of the sha256-586.pl script that was posted here before on May 11th.
version 11/05/2015:
sha256 39017.64k 87648.54k 150106.58k 183705.94k
197330.99k
version 1.8:
sha256 33560.42k 73153.83k 121472.43k 167948.67k
180955.23k
all my tests were done using 'openssl speed sha256' , I'm unsure how you
did your testing.
cheers,
JJK / Jan Just Keijser
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
