Ciao,
Il Ven, 8 Febbraio 2013 11:42 am, Torbjorn Granlund ha scritto:
> bodr...@mail.dm.unipi.it writes:
> I agree, but ... the only difference I could see on my netbook is not
> memory alignment, but "position".
>
> Was this reproduced on any non-Linux system? Perhaps Linux somehow
> messes up caching and/or TLD for certain address ranges?
The timings I posted on this list was measured on shell, a FreeBSD system.
I tested my patch on my netbook (atom-linux) and shell (K10-fbsd), on both
mul results was worst than mul_n results before the patch, and equivalent
after it.
Removing the (now pushed) patch, on shell I obtain:
$ tune/speed -o addrs -s 800000 mpn_mul_n
mpn_mul_n
dst 801E00040 src 800E00040 801600040 (cf sp approx 7FFFFFFFC37C)
800000 0.646598000
$ tune/speed -o addrs -s 800000 mpn_mul
mpn_mul
dst 801E00040 src 802C00040 801600040 (cf sp approx 7FFFFFFFC36C)
800000 0.680945000
Different addresses, different speed.
With the patch, always on shell, I get:
$ tune/speed -o addrs -s 800000 mpn_mul_n
mpn_mul_n
dst 801E00040 src 800E00040 801600040 (cf sp approx 7FFFFFFFC37C)
800000 0.644599000
$ tune/speed -o addrs -s 800000 mpn_mul
mpn_mul
dst 801E00040 src 800E00040 801600040 (cf sp approx 7FFFFFFFC36C)
800000 0.645062000
Same addresses, same speed.
--
http://bodrato.it/papers/
_______________________________________________
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
