Misaki, >> The measurement I sent yesterday for OpenSSL (with inlined T4 >> instruction support) was not quite accurate. >> Some of the T4 specific code you committed was not enabled when we >> tested, and I realized that __sparc__ was not defined on our system. >> Thus, I changed "#if defined(__sparc__)" to "#if defined(__sparc)". >> Now, we are seeing better number with OpenSSL. >> >> sign verify sign/s verify/s >> rsa 1024 bits 0.000351s 0.000024s 2852.9 42311.0 >> rsa 2048 bits 0.001258s 0.000047s 795.1 21128.6 >> rsa 4096 bits 0.006240s 0.000395s 160.3 2533.3 > > Which is virtually identical to Linux results. So one mystery solved. > I'll commit the fix at some later point. > >> which is still slower than our t4 engine for 1k and 2k bit RSA sign: >> sign verify sign/s verify/s >> rsa 1024 bits 0.000237s 0.000028s 4221.9 36119.8 >> rsa 2048 bits 0.000876s 0.000075s 1141.7 13285.6 >> rsa 4096 bits 0.006341s 0.002139s 157.7 467.5 > > As mentioned the problem seems to be "multi-layer" and we are moving in > right direction.
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4ddacd9921f48013b5cd011e4b93b294c14db1c2 improves RSA sign performance by 20-30%: rsa 1024 bits 0.000256s 0.000016s 3904.4 61411.9 rsa 2048 bits 0.000946s 0.000029s 1056.8 34292.7 rsa 4096 bits 0.005061s 0.000340s 197.6 2940.5 This is still slower than your code, but conclusion we have to draw is that it's intentional. In sense that the discrepancy is accounted to the fact that OpenSSL implements counter-measures against cache-timing attack, and takes rather conservative approach. It remains to be seen if platform-specific and faster counter-measure will be suggested at later point. Meanwhile, please double-check on Solaris. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
