Dear Marco,
> > I don't see mpn_zero_p in the API of the current stable version 6.0.0
> > (according to gmplib.org). In which version will it be available?
>
> It will be available from the next release.
great! Looking forward for the next release...
Paul
Ciao,
Il Lun, 18 Maggio 2015 11:33 am, paul zimmermann ha scritto:
> I don't see mpn_zero_p in the API of the current stable version 6.0.0
> (according to gmplib.org). In which version will it be available?
It will be available from the next release.
As the manual says about low-level functions:
Ciao,
Il Gio, 21 Maggio 2015 7:09 pm, Torbjörn Granlund ha scritto:
> I suppose this bug means that we didn't really provide mpn_com in the
> public interface. Perhaps we should mention it in NEWS?
It depends, on some platforms we did, on other platforms we didn't. It was
a bug, and we should me
bodr...@mail.dm.unipi.it writes:
But it is not an inline function, it's a macro redefining mpn_com, it will
not conflict with the prototype __gmpn_com. (I hope ;-)
Thanks, it seems to have helped.
I suppose this bug means that we didn't really provide mpn_com in the
public interface. Perh
Ciao,
Il Mar, 19 Maggio 2015 10:02 am, Niels Möller ha scritto:
> The declaration of mpn_com looks a bit fishy. It's conditionally declared
> in gmp-h.in, inside an
>
> #if __GMP_INLINE_PROTOTYPES || defined (__GMP_FORCE_mpn_com)
>
> But the inline definition is in gmp-impl.h, not gmp-h.in, so n
Marco,
> Well, you use mpn_com_n (it have never been in the official API), you
> #include "gmp-impl.h" ...
you are right. However if I want to only use the official API then:
* I have to use malloc instead of TMP_ALLOC_LIMBS (fine)
* I need invert_limb (referenced in the 6.0.0 manual but
t...@gmplib.org (Torbjörn Granlund) writes:
> There are new build failures which seem related to this change.
The declaration of mpn_com looks a bit fishy. It's conditionally declared
in gmp-h.in, inside an
#if __GMP_INLINE_PROTOTYPES || defined (__GMP_FORCE_mpn_com)
But the inline definition
There are new build failures which seem related to this change.
--
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-devel mailing list
gmp-devel@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-devel
Ciao Paul,
Il Lun, 18 Maggio 2015 11:33 am, paul zimmermann ha scritto:
>> > mpn_neg_n (tp, tp, n);
>
> should be mpn_neg instead? I have put this in
Yes, of course.
>> Anyway, in your code you should probably write:
>>mpn_com (tp + l, tp + l, h); /* Amended the _n ;-) */
>>mpn_add
bodr...@mail.dm.unipi.it writes:
> @shell ~/gmp-repo$ tune/speed -s 1-1030 -f 2 -c mpn_neg mpn_com
You might want to pass -p100 or somesuch to allow the CPU to speed
up. (We might want to change the default, not sure to what.)
--
Torbjörn
Please encrypt, key id 0xC8601622
___
> Now we have:
>
> @shell ~/gmp-repo$ tune/speed -s 1-1030 -f 2 -c mpn_neg mpn_com
> overhead 6.77 cycles, precision 1 units of 2.86e-10 secs, CPU freq
> 3500.08 MHz
> mpn_neg mpn_com
> 1 #3.41 12.53
> 2 20.38#13.64
> 4
bodr...@mail.dm.unipi.it writes:
> I pushed Niels' code for mpn_neg. The old timings was:
Thanks!
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
g
bodr...@mail.dm.unipi.it writes:
The new code is faster for n==1, slower for 2 <= n <= 4, and faster (more
than twice) for n >= 16.
Nice speedup! In mpn/x86_64/fastsse/com.asm we have an mpn_com which
will speed things up another 2x. It is not enabled on any platforms now
as it needs twea
Ciao,
I pushed Niels' code for mpn_neg. The old timings was:
> @shell ~/gmp-repo$ tune/speed -s 1-1030 -f 2 -c mpn_neg mpn_com
> mpn_add_1_inplace.1
> overhead 6.78 cycles, precision 1 units of 2.86e-10 secs, CPU freq
3500.08 MHz
> mpn_neg mpn_com mpn_add_1_inplace.1
> 1
was fun writing it.
I applied most of the short-cuts to your special n==2 code, it's not as
readable as it was, but it should be faster. I attach a diff.
>> Il Mar, 3 Febbraio 2015 7:09 pm, paul zimmermann ha scritto:
>> > I did update my notes and code about fast inversion (whic
I just noticed that the fast mpn_com in x86_64/fastsse is not really
used, making calls to mpn_com from the inlined mpn_neg perform poorly.
I'll address this soon.
--
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-devel mailing list
gmp-devel@gmpli
Ciao,
Il Mer, 29 Aprile 2015 10:49 am, t...@gmplib.org ha scritto:
> ni...@lysator.liu.se (Niels Möller) writes:
mp_limb_t
mpn_neg (mp_ptr rp, mp_srcptr up, mp_size_t n)
{
/* Low zero limbs are unchanged by negation. */
while (*up == 0)
{
*rp = 0;
if (!--n)
t...@gmplib.org writes:
> Not sure why we're doing this as an inline function in gmp.h.
>
> Me neither. Perhaps as it is tiny?
I think inlines in gmp.h makes sense for functions which are tiny and
O(1) in the common case, like mpn_add_1 and mpn_cmp. Or small O(1)
wrappers around O(n) functi
ni...@lysator.liu.se (Niels Möller) writes:
I'd suggest something like this (totally untested)
mp_limb_t
mpn_neg (mp_ptr rp, mp_srcptr up, mp_size_t n)
{
/* Low zero limbs are unchanged by negation. */
while (*up == 0)
{
*rp++ = 0;
up++;
On 2015-04-29 07:01:39 +0200, bodr...@mail.dm.unipi.it wrote:
> diff -r 6e11cd70e19e gmp-h.in
> --- a/gmp-h.inMon Apr 27 22:46:53 2015 +0200
> +++ b/gmp-h.inTue Apr 28 22:41:52 2015 +0200
> @@ -2191,13 +2191,10 @@
> mp_limb_t
> mpn_neg (mp_ptr __gmp_rp, mp_srcptr __gmp_up, mp_siz
bodr...@mail.dm.unipi.it writes:
> mpn_neg id defined in gmp.h, where we can not check for HAVE_NATIVE, but I
> suspect that also the C version of mpn_com is faster than mpn_neg (in the
> former, limbs do not depend on one another, no "carry" propagation).
I'd suggest something like this (totally
Ciao,
Il Lun, 27 Aprile 2015 4:45 pm, t...@gmplib.org ha scritto:
> @shell ~/gmp-repo$ tune/speed -s 1-1030 -f 2 -c mpn_neg mpn_com
> mpn_add_1_inplace.1
> overhead 6.78 cycles, precision 1 units of 2.86e-10 secs, CPU freq
> 3500.08 MHz
> mpn_neg mpn_com mpn_add_1
bodr...@mail.dm.unipi.it writes:
After a first glance to the code, two lines surprise me:
mpn_com_n (tp, tp, n);
mpn_add_1 (tp, tp, n, ONE);
I wondered why you didn't use
mpn_neg_n (tp, tp, n);
Then I tested (on shell@gmplib) and...
@shell ~/gmp-repo$ tune/speed
or the long delay, I've been off-line for a long while...
>
> Il Mar, 3 Febbraio 2015 7:09 pm, paul zimmermann ha scritto:
> > I did update my notes and code about fast inversion (which were used as
> > basis for Algorithm 3.5 ApproximateReciprocal in "Modern Computer
>
Ciao Paul!
Sorry for the long delay, I've been off-line for a long while...
Il Mar, 3 Febbraio 2015 7:09 pm, paul zimmermann ha scritto:
> I did update my notes and code about fast inversion (which were used as
> basis for Algorithm 3.5 ApproximateReciprocal in "Modern Comp
Hi,
I did update my notes and code about fast inversion (which were used as basis
for Algorithm 3.5 ApproximateReciprocal in "Modern Computer Arithmetic"):
http://www.loria.fr/~zimmerma/papers/invert.{c,pdf}
The main change is that now the result is uniquely defined (instead
26 matches
Mail list logo
