Looks like this function is primarily to obliterate the values from memory. This will most definitely cause cache-misses costing the performance to tank. A better way would be to use platform specific constructs to zero the entire cache-line. This should be a compile time option or possible a engine specific implementation, which may use its own function.
Piras On Thu, Jan 15, 2009 at 1:28 PM, schoppert <br...@schoppert.com> wrote: > > While trying to diagnose a performance issue with my software, I noticed > that > sha1 performance on Solaris has taken a huge hit since 0.9.6b ( I am > upgrading a very old client program ). > > After running some speed tests, I found that in 0.9.6b sha1(64) was 14762k > but in 0.9.8j it is only 6593k ... less than half. I did a little more > work > to find that later versions of 0.9.6 also suffered performance issues due > to > the introduction on OPENSSL_cleanse() ... replacing that method with a > simpler model ( for testing ) brought performance back up. > > But, with 0.9.7, 0.9.8 and 0.9.9 snapshot, replacing the cleanse function > does not help. And, although the assembly language changes in 0.9.9 > dramatically improve RSA performance, sha1(64) has sunk even lower than > before ... clocking in a measly 4992k. > > So, I was wondering if there were any plans to address this trend, or > anything I can call or configure to help ... at this point, my only > immediate choice is to use old code from 0.9.6 since I cannot afford the > performance hit with anything newer. > > > -- > View this message in context: > http://www.nabble.com/poor-sha1-performance-on-Solaris-8-tp21485121p21485121.html > Sent from the OpenSSL - Dev mailing list archive at Nabble.com. > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org > -- Online Gallery: http://www.deptons.com You comments and ratings are very welcome!!
