
wk at gnupg
Jul 19, 2006, 5:39 AM
Post #1 of 1
(828 views)
Permalink
|
|
Profiling (was: Faster mutex lock() and unlock())
|
|
On Thu, 13 Jul 2006 15:40, Nikos Mavrogiannopoulos said: > time samples samples calls T1/call T1/call name > 23.55 1247.00 1247.00 Loop > 16.37 2114.00 867.00 Loop > 14.41 2877.00 763.00 gcry_mpih_divrem This shows that the big number operations are taking up most of the time. This is expected. If someone is really up to modern ia32 CPUs this can be optimized. I know that meanwhile GMP has better optimizations but due to their configuration change in the assembler functions, it is not straightforward to port them back to libgcrypt. It is of course possible and should be done. before you ask: No, libgcrypt's current configuration scheme is not subject to a change becuase we know that it works and is portable over a wide range of platforms. > 8.63 3334.00 457.00 rijndael_encrypt The current AES code is pretty standard the reference implementation. It should be possible to squeeze out more performance and maybe even make cache timing atatcks harder. Briand Gladman put quite some work in optimized implementations (http://fp.gladman.plus.com/AES/index.htm). I just noticed that the new license terms allow distribution under the GPL - so we could take the code and add it to libgcrypt using an configure option to still allow building an LGPL version of libgcrypt. If we use this code as an alternative AES implenemtation, I think it will be okay with the GNU coding standards to go without a copyright disclaimer in this case. That alternative code should be clearly separated, though. Needs a volunteer of course ;-) > 5.44 3622.00 288.00 transform Ah well, SHA-1. We should definitely look for an optimized version as SHA-1 is really often and can lead to a real performance problem. For example GnupG runs not only AES but also SHA-1 over the bulk data. The benchmark tool could give some hints on the current performance. > 3.76 3821.00 199.00 transform I guess this is another hash algorithm - probably ripe-md160 as used by the RNG. Salam-Shalom, Werner _______________________________________________ Gcrypt-devel mailing list Gcrypt-devel [at] gnupg http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
|