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
Marco,
Date: Wed, 6 Feb 2013 17:59:44 +0100 (CET)
From: bodr...@mail.dm.unipi.it
Ciao Paul!
Ciao!!!
Of course. With current implementation, unbalanced multiplications need
some more memory and a few additions/subtractions, but this should not
give a measurable slow-down. The
Zimmermann Paul paul.zimmerm...@loria.fr writes:
if the culprit is the macro used in speed, it should be fixed!
I stared at it for an hour yesterday, and I cannot see any problems.
Operand alignment will differ, but then we shouldn't get consistently
worse performance from mpn_mul.
--
mpn_mul_n mpn_mul mpn_mul_n mpn_mul
800.660041000 #0.656041000 0.660041000 0.660041000
There is a side-effect: to measure the speed of unbalanced multiplication,
eg ## x ##, you used
tune/speed -s ## mpn_mul.##
now the roles of the two parameters
Ciao Niels,
Il Gio, 7 Febbraio 2013 10:29 am, Niels Möller ha scritto:
I don't understand the details, like the align parameter to the
Unfortunately, it's the same for me... I only tried to mimic the MPN_MUL_N
macro.
Makes sense to me to have the r parameter give the size of the smaller
bodr...@mail.dm.unipi.it writes:
If other developers does not dislike the changed meaning of the .r
parameter to mpn_mul, this patch can be applied to the main repo...
I don't mind, since I never remember which way it is anyway.
Avoiding the local allocation is nice too.
It would be nice
Ciao Torbjorn,
Il Gio, 7 Febbraio 2013 11:22 am, Torbjorn Granlund ha scritto:
It would be nice to understand the slowdown of before, though...
I agree, but ... the only difference I could see on my netbook is not
memory alignment, but position.
Before the patch, I obtain:
$ tune/speed -o
Ciao Paul!
Il Dom, 27 Gennaio 2013 10:09 am, Zimmermann Paul ha scritto:
In the FTT range, multiplying n limbs by m limbs should not be more
expensive then multiplying two numbers of (n+m)/2 limbs.
Of course. With current implementation, unbalanced multiplications need
some more memory and a
Marco,
Date: Sat, 26 Jan 2013 16:21:28 +0100 (CET)
From: bodr...@mail.dm.unipi.it
Ciao,
Il Sab, 26 Gennaio 2013 4:01 pm, bodr...@mail.dm.unipi.it ha scritto:
I mean, which timing do you obtain with the following?
./speed -s $((100+775660)/2) mpn_mul_n mpn_mul_n
Sorry...
Zimmermann Paul paul.zimmerm...@loria.fr writes:
in GMP 5.1.0, a multiplication of n x m limbs for m n can be slower than
a multiplication of n x n limbs. Compare for example the line starting with
775660 in the first output from speed, and the one starting with 100 in
the second one
Ciao Paul,
Il Ven, 25 Gennaio 2013 9:24 pm, Zimmermann Paul ha scritto:
in GMP 5.1.0, a multiplication of n x m limbs for m n can be slower than
a multiplication of n x n limbs. Compare for example the line starting
mpn_mul.100 mpn_mul.100
775660 #0.740046000 0.744046000
Hi,
in GMP 5.1.0, a multiplication of n x m limbs for m n can be slower than
a multiplication of n x n limbs. Compare for example the line starting with
775660 in the first output from speed, and the one starting with 100 in
the second one below.
frite% ./speed -s 50-100 -f
12 matches
Mail list logo
