On Fri, 2010-04-02 at 15:57 -0400, Victor Duchovni wrote: > The performance of the 1.0.0 AES algorithm as reported by "openssl speed", > appears to be much lower with block sizes of 16, 64 and 256 bytes than > with previous releases. Larger block sizes of 1024 and 8192 bytes show > good performance. Is this to be expected? Tests were run on a RedHat > Linux system with an Intel X86-64 CPU for both the 32-bit and 64-bit > builds of the code. Should lower AES performance for small buffer sizes > be expected with 1.0.0, or is "speed aes" reporting inaccurate data?
I investigated this a little. You compared various 0.9.x revisions with 1.0.0, but there's a _big_ jump between those branches, and I wanted to look at the history of the branch which became 1.0.0 (or current HEAD, which is close enough). Obviously the first thing to do was to import the code into a modern version control system so that I could actually do useful things with it. I used Keith Packard's parsecvs to create a git repository, which I've put at http://git.infradead.org/users/dwmw2/openssl-parsecvs.git My testing was done on an 8-way Tylersburg-HEDT system, with cpu speed pinned at 3GHz to avoid complications from power saving. It runs Fedora 11, with GCC 4.4.1. I tested only 64-bit. I started with current HEAD, then stepped back by 100 commits at a time, rebuilding with default options from ./config then running 'openssl speed aes' and charting the results -- which are at http://david.woodhou.se/aesspeed.png (and .dat and .gnuplot). As you can see, the results all got much faster once I got back in time to about mid-2007. Using 'git-bisect' I was able to find the offending commit which had caused the performance degradation: http://git.infradead.org/users/dwmw2/openssl-parsecvs.git/commitdiff/25e9f96b Another interesting thing that you can't quite make out on the graph is that there was a significant _improvement_ in aes128-cbc and aes192-cbc performance on smaller sizes immediately before it got worse. See the data for commit id 1a1c46a9f4df4fa3fcfa5343cdd7136e164bae27 in the raw results. Note that I didn't bisect this change so it's almost certainly not precisely that commit which caused it. And that aes256-cbc performance got worse while aes128-cbc and aes192-cbc got better. I resisted the temptation to include AESNI scores on the graph; they'd have screwed up the scale :) -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
