From c94b6de0171d2f71a643e6eac778b417d938080e Mon Sep 17 00:00:00 2001 From: =?utf8?q?Bodo=20M=C3=B6ller?= Date: Tue, 28 Nov 2000 11:47:51 +0000 Subject: [PATCH] Timings. --- crypto/bn/bn_exp.c | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/crypto/bn/bn_exp.c b/crypto/bn/bn_exp.c index e6b3a5f5f9..eab394b962 100644 --- a/crypto/bn/bn_exp.c +++ b/crypto/bn/bn_exp.c @@ -169,12 +169,25 @@ int BN_mod_exp(BIGNUM *r, const BIGNUM *a, const BIGNUM *p, const BIGNUM *m, * exponentiation using the reciprocal-based quick remaindering * algorithm is used. * - * (For computations a^p mod m where a, p, m are of the same - * length, BN_mod_exp_recp takes roughly 50 .. 70 % the time - * required by the standard algorithm, and BN_mod_exp takes - * about 33 .. 40 % of it. - * [Timings obtained with expspeed.c on a AMD K6-2 platform under Linux, - * with various OpenSSL debugging macros defined. YMMV.]) + * (Timing obtained with expspeed.c [computations a^p mod m + * where a, p, m are of the same length: 256, 512, 1024, 2048, + * 4096, 8192 bits], compared to the running time of the + * standard algorithm: + * + * BN_mod_exp_mont 33 .. 40 % [AMD K6-2, Linux, debug configuration] + * 55 .. 77 % [UltraSparc processor, but + * debug-solaris-sparcv8-gcc conf.] + * + * BN_mod_exp_recp 50 .. 70 % [AMD K6-2, Linux, debug configuration] + * 62 .. 118 % [UltraSparc, debug-solaris-sparcv8-gcc] + * + * On the Sparc, BN_mod_exp_recp was faster than BN_mod_exp_mont + * at 2048 and more bits, but at 512 and 1024 bits, it was + * slower even than the standard algorithm! + * + * "Real" timings [linux-elf, solaris-sparcv9-gcc configurations] + * should be obtained when the new Montgomery reduction code + * has been integrated into OpenSSL.) */ #define MONT_MUL_MOD -- 2.34.1