To get an idea of the performance of this library, use
ssleay speed
perl util/sp-diff.pl file1 file2
will print out the relative differences between the 2 files which are
expected to be the output from the speed program.
The performace of the library is very dependant on the Compiler
quality and various flags used to build.
---
These are some numbers I did comparing RSAref and SSLeay on a Pentium 100.
[ These numbers are all out of date, as of SSL - 0.6.1 the RSA
operations are about 2 times faster, so check the version number ]
RSA performance.
SSLeay 0.6.0
Pentium 100, 32meg, Windows NT Workstation 3.51
linux - gcc v 2.7.0 -O3 -fomit-frame-pointer -m486
and
Windows NT - Windows NT 3.51 - Visual C++ 4.1 - 586 code + 32bit assember
Windows 3.1 - Windows NT 3.51 - Visual C++ 1.52c - 286 code + 32bit assember
NT Dos Shell- Windows NT 3.51 - Visual C++ 1.52c - 286 code + 16bit assember
Times are how long it takes to do an RSA private key operation.
512bits 1024bits
-------------------------------
SSLeay NT dll 0.042s 0.202s see above
SSLeay linux 0.046s 0.218s Assember inner loops (normal build)
SSLeay linux 0.067s 0.380s Pure C code with BN_LLONG defined
SSLeay W3.1 dll 0.108s 0.478s see above
SSLeay linux 0.109s 0.713s C without BN_LLONG.
RSAref2.0 linux 0.149s 0.936s
SSLeay MS-DOS 0.197s 1.049s see above
486DX66, 32meg, Windows NT Server 3.51
512bits 1024bits
-------------------------------
SSLeay NT dll 0.084s 0.495s <- SSLeay 0.6.3
SSLeay NT dll 0.154s 0.882s
SSLeay W3.1 dll 0.335s 1.538s
SSLeay MS-DOS 0.490s 2.790s
What I find cute is that I'm still faster than RSAref when using standard C,
without using the 'long long' data type :-), %35 faster for 512bit and we
scale up to 3.2 times faster for the 'default linux' build. I should mention
that people should 'try' to use either x86-lnx.s (elf), x86-lnxa.s or
x86-sol.s for any x86 based unix they are building on. The only problems
with be with syntax but the performance gain is quite large, especially for
servers. The code is very simple, you just need to modify the 'header'.
The message is, if you are stuck using RSAref, the RSA performance will be
bad. Considering the code was compiled for a pentium, the 486DX66 number
would indicate 'Use RSAref and turn you Pentium 100 into a 486DX66' :-).
[ As of verson 0.6.1, it would be correct to say 'turn you pentium 100
into a 486DX33' :-) ]
I won't tell people if the DLL's are using RSAref or my stuff if no-one
asks :-).
eric
PS while I know I could speed things up further, I will probably not do
so due to the effort involved. I did do some timings on the
SSLeay bignum format -> RSAref number format conversion that occurs
each time RSAref is used by SSLeay, and the numbers are trivial.
0.00012s a call for 512bit vs 0.149s for the time spent in the function.
0.00018s for 1024bit vs 0.938s. Insignificant.
So the 'way to go', to support faster RSA libraries, if people are keen,
is to write 'glue' code in a similar way that I do for RSAref and send it
to me :-).
My base library still has the advantage of being able to operate on
any size numbers, and is not that far from the performance from the
leaders in the field. (-%30?)
[ Well as of 0.6.1 I am now the leader in the filed on x86 (we at
least very close :-) ]
I suppose I should also mention some other numbers RSAref numbers, again
on my Pentium.
DES CBC EDE-DES MD5
RSAref linux 830k/s 302k/s 4390k/s
SSLeay linux 855k/s 319k/s 10025k/s
SSLeay NT 1158k/s 410k/s 10470k/s
SSLeay w31 378k/s 143k/s 2383k/s (fully 16bit)
Got to admit that Visual C++ 4.[01] is a damn fine compiler :-)
--
Eric Young | BOOL is tri-state according to Bill Gates.
AARNet: eay@mincom.oz.au | RTFM Win32 GetMessage().