Ciao Niels!
Il Ven, 11 Novembre 2011 4:21 pm, Niels ha scritto:
The input sizes to mpn_mulmod_bnm1 is then 3n x n. How well suited is
current mpn_mulmod_bnm1 to these unbalanced operands?
The cost of current mpn_mulmod_bnm1 implementation does not really depend
on how much balanced the
Ciao!
Il Mer, 7 Dicembre 2011 8:30 pm, Torbjorn Granlund ha scritto:
There is a step (for the old and new code) at about n=20. Only for
There is a table generated by gen-fac_ui.c ... 20! 2^64 21!
Would you consider migrating this to mpn at some point, or is there a
reason to keep it at
Ciao!
Il Ven, 9 Dicembre 2011 2:39 pm, Torbjorn Granlund ha scritto:
The code is about 2.5 times faster than the old code, at least for
arguments of the type 2n over n. (This code as well as the old code is
still slow for large operands; we need a factorisation based algorithm
over a
Ciao,
Il Lun, 19 Dicembre 2011 6:47 pm, bodr...@mail.dm.unipi.it ha scritto:
Il Lun, 19 Dicembre 2011 10:14 am, Niels Möller ha scritto:
Maybe there's no better way to compute the number of primes than to
use the sieve of Erathostenes' to generate them all?
To have the exact count, I believe
Il Mer, 21 Dicembre 2011 1:36 pm, Niels Möller ha scritto:
bodr...@mail.dm.unipi.it writes:
I imagine this interface is for efficiently generating a large number of
small primes. For large primes, one would have to iterate over
mpz_nextprime. Are there any large savings from storing
Ciao,
Il Mer, 22 Febbraio 2012 7:41 pm, Torbjorn Granlund ha scritto:
Marc Glisse marc.gli...@inria.fr writes:
their length. By the way, is there any difference between PTR and
LIMBS? Say one that should be used in some circumstances and one in
others?
You're welcome to clean up
Il Mer, 22 Febbraio 2012 8:32 pm, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
Unrelated :-) We might define more macros like TMP_ALLOC_LIMBS_2 . I
Please look at the generated code from TMP_ALLOC from any reasonable
compiler. It is a sub from sp, the a copy from sp to
Ciao,
Il Ven, 24 Febbraio 2012 10:40 am, Torbjorn Granlund ha scritto:
I cannot see how TMP_ALLOC_LIMBS_2 could save *anything* for small
I'm not sure I agree with Torbjorn. Nevertheless developers time is a far
more precious resource than a few cpu cycles or bytes of code size...
That's why I
Ciao!
The implementation of mpz_invert in GMP 5.0.4, called with
mpz_invert (x, 1, 0), return x=1, i.e. it gives 1 as the inverse of 1
modulo zero.
I recently changed the behaviour of that function in the main repo:
http://gmplib.org:8000/gmp/rev/ac67d45cb24e
I'd like to backport this change to
Ciao,
Il Lun, 5 Marzo 2012 6:58 pm, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
I'd like to backport the test and the documentation changes to 5.0, now.
Be my guest... (We should perhaps do this sort of things, even without
expecting more 5.0 releases.)
The likeliness
Ciao,
Il Gio, 8 Marzo 2012 10:26 am, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
Do you agree with the attached patch?
Looks good to me. (I assume you have compiled the lot.)
Tested it on shell and on my computer. Nightly tests will confirm or
not... I pushed it.
--
Ciao,
Il Mar, 27 Marzo 2012 6:31 pm, Torbjorn Granlund ha scritto:
I believe we will need a GMP 5.0.5 release.
(1) GMP 5.0.4 recognises AMD 11h processors as 10h (aka K10), then
(2) GMP 5.0.4 fails to recognise newer Intel sandybridge processors due
Any other urgent changes needed?
None.
Ciao!
I played a little bit with mpn/x86_64/sqr_basecase.asm, it contains
instructions like:
add $-40, %rsp
mov %rbx, 32(%rsp)
mov %rbp, 24(%rsp)
mov %r12, 16(%rsp)
mov %r13, 8(%rsp)
mov %r14, (%rsp)
From the document I've
Ciao,
Il Ven, 13 Aprile 2012 10:53 am, Marc Glisse ha scritto:
It is a different information, but a code coverage tool run during the
testsuite tells which functions are never called there (on one specific
platform, with one set of options):
Ciao!
I pushed some new code in the main repository:
- a prime-factor-based implementation for the binomial,
- a new function to compute the primorial.
Both are based on the bit-wise prime-sieve I wrote for the factorial,
that's why I moved it in the main directory, it is now called
Ciao!
Il Gio, 19 Aprile 2012 2:23 pm, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
The current mpz_primorial_ui function is almost trivial, it sieves all
primes up to the given limit (storing the full bit-array), then it
It seems wasteful to maintain the full bit array,
Ciao!
Il Ven, 20 Aprile 2012 8:42 am, bodr...@mail.dm.unipi.it ha scritto:
Il Gio, 19 Aprile 2012 2:23 pm, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
The current code uses the basecase below an hard-coded threshold on K,
and anytime K N/16. Tuning, and a deeper
Dear Lhoussain,
Il Lun, 23 Aprile 2012 10:36 am, Lhoussain Aitassou ha scritto:
I would be interested to participate to the development of GMP library.
These points would interest me :
Factorial
I rewrote the code for factorial (mpz_fac_ui) a couple of months ago
Ciao,
Il Ven, 27 Aprile 2012 12:47 pm, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
#define ABOVE_THRESHOLD(size,thresh)
\
((thresh) == 0\
|| ((thresh) != MP_SIZE_T_MAX
Ciao,
Il Lun, 23 Aprile 2012 7:13 pm, bodr...@mail.dm.unipi.it ha scritto:
we should probably add also a general multi-factorial function
We have it now. It is a simple function, but it should be fast enough.
The new function is mpz_mfac_uiui(r, n, m).
mpz_mfac_uiui(r, n, 1), sets r = n!
Ciao,
Il Dom, 6 Maggio 2012 7:20 am, bodr...@mail.dm.unipi.it ha scritto:
Il Ven, 27 Aprile 2012 12:47 pm, Torbjorn Granlund ha scritto:
I am not sure exactly what behaviour change you are trying to achieve,
but I assume it is good. :-)
I pushed a few changes to the MAYBE_ mechanism of
Ciao,
Il Dom, 6 Maggio 2012 11:51 am, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
I pushed a few changes to the MAYBE_ mechanism of lower degree toom
functions, and to the ABOVE_THRESHOLD macro (only for GCC).
Why would tuneup be affected?
The ABOVE_THRESHOLD macro
Ciao,
Il Dom, 6 Maggio 2012 11:48 am, bodr...@mail.dm.unipi.it ha scritto:
Another possible change might be moving the initialized filed outside the
__gmpn_cpuvec struct.
I'm trying.
Toom-2 and Toom-3 code for fat builds should be basically equivalent to
the code used by tuneup, now: the
Ciao,
I'm looking inside the mpq directory, to perform something similar to
Torbjorn's change mpz: Use MPZ_REALLOC return value when possible,
that's why I revive an old question...
Il Ven, 24 Febbraio 2012 12:32 pm, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
I always
Ciao,
Il Gio, 31 Maggio 2012 6:24 pm, Marc Glisse ha scritto:
On Thu, 31 May 2012, Richard Guenther wrote:
KVM unfortunately defaults to an impossible CPU model/family on x86_64
(GeneInuintel, family 6, model 2). This leads to
Unfortunately GMP code classify this model/family as 32-bit
Ciao!
Il Ven, 1 Giugno 2012 9:16 am, Marc Glisse ha scritto:
On Fri, 1 Jun 2012, bodr...@mail.dm.unipi.it wrote:
- should we ask for a fourth function (alloc, free,
conservative_realloc,
nonconservative_realloc)?
If the usual allocators don't provide it, it is inconvenient to require
Both
Ciao,
Il Sab, 2 Giugno 2012 6:32 pm, Niels Möller ha scritto:
Torbjorn Granlund t...@gmplib.org writes:
I thought avoiding the copying was a good idea, but this thread has made
me less sure.
I guess some benchmarks are needed here.
That's why I did not propose to change the behavior of the
Ciao,
Il Lun, 4 Giugno 2012 6:32 pm, Torbjorn Granlund ha scritto:
Pedro Gimeno p.gim...@formauri.es writes:
Also, I seem to remember there were plans to make a new version of
mpz_nextprime accepting a random state and the number of M-R tests, and
of mpz_probab_prime_p accepting a
Ciao,
Il Ven, 8 Giugno 2012 10:28 pm, Marc Glisse ha scritto:
((mp_ptr) res)[0] = ~ ((mp_ptr) res)[ALLOC (z) - 1];
Won't valgrind complain about an uninitialized read here?
It shouldn't! I read from the manual of Valgrind:
http://valgrind.org/docs/manual/mc-manual.html#mc-manual.uninitvals
/papers//* mpz_stronglucasselfridge_p --
An implementation of the probabilistic primality test described in
http://en.wikipedia.org/wiki/Lucas_pseudoprime , with parameters
detailed as in http://en.wikipedia.org/wiki/Baillie-PSW_primality_test
Copyright 2012 by Marco Bodrato.
This program is free
Ciao!
1) mpz/generic/sizeinbase.c is unused.
Should we remove it? Or, at least, write it as:
size_t
mpn_sizeinbase (mp_srcptr xp, mp_size_t xsize, int base)
{
size_t result;
MPN_SIZEINBASE (result, xp, xsize, base);
return result;
}
2) gmp-impl.h defines the unused macro
This discussion begun on gmp-bugs, was moved to gmp-discuss... I reply to
gmp-devel to avoid confusions for the users, because the problem I've
found arise with the current head repository only.
Vincent Lefevre vinc...@vinc17.net writes:
Not to remove it, but to make it *optional*, i.e. to
Ciao,
Il Mer, 20 Giugno 2012 9:54 pm, Niels Möller ha scritto:
I think it makes sense to have --disable-assembly disable *all* use of
assembly source files.
Agreed.
For configure.in hacks, after a quick look I think what needs to be done
is to have --disable-assembly disable any setting of
Ciao,
Il Ven, 15 Giugno 2012 7:07 am, Niels Möller ha scritto:
bodr...@mail.dm.unipi.it writes:
About documentation... shall we explicitly document a supported way to
obtain an mpn form an mpz, and viceversa? The following should always
...
mpz_export (np, nn, -1, sizeof(mp_limb_t), 0,
, 1993, 1994, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2005 Free
Software Foundation, Inc. Miller-Rabin code contributed by John Amanatides.
Copyright 2012, Marco Bodrato
This file is not yet part of anything, but intended for the GNU MP Library.
This file is free software; you can redistribute
Ciao,
Il Gio, 21 Giugno 2012 6:47 pm, bodr...@mail.dm.unipi.it ha scritto:
Il Mer, 20 Giugno 2012 9:54 pm, Niels Möller ha scritto:
For configure.in hacks, after a quick look I think what needs to be done
is to have --disable-assembly disable any setting of
HAVE_CALLING_CONVENTIONS (config.h
Ciao Niels, ciao Paul!
Il Lun, 17 Dicembre 2012 9:07 pm, Niels Möller ha scritto:
Zimmermann Paul paul.zimmerm...@loria.fr writes:
frite% gcc -I$GMP/include -O2 -g e.c $GMP/lib/libgmp.a
frite% ./a.out
GMP: header 5.0.5, library 5.0.5
mpz_jacobi: 408ms
frite% gcc -I/tmp/include -O2 -g
Ciao,
Il Gio, 27 Dicembre 2012 12:12 pm, Niels ha scritto:
Torbjorn Granlund t...@gmplib.org writes:
I thought we had discussed this. The change is fine, optimising the
common case is a great thing in general.
Unfortunately, the common case is not tested by our testsuite!
Ciao,
Il Gio, 27 Dicembre 2012 10:39 pm, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
Unfortunately, the common case is not tested by our testsuite!
http://hydra.nixos.org/build/3594794/download/1/coverage/mpz/combit.c.gcov.html
Only check-mini-gmp stress-tests it
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
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
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
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,
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
Ciao!
I played with gmpxx.h for a while, because Torbjorn said something about
possible functions for comparison with shortcuts to detect specific
conditions (, =, or )...
After some tests with C++ I moved my experiments to plain C.
The current status of the experiments is shown by the attached
Ciao,
Il Dom, 3 Marzo 2013 7:13 pm, Torbjorn Granlund ha scritto:
ni...@lysator.liu.se (Niels Möller) writes:
I didn't list __gmpn_add_n_sub_n as public since I consider it
experimental. It seemed like a good idea, but I never managed to make
it faster, not even for the large
Ciao,
Il Dom, 3 Marzo 2013 5:53 pm, Torbjorn Granlund ha scritto:
ni...@lysator.liu.se (Niels Möller) writes:
__gmpn_sqr_basecase
This (and also mul_basecase) should be public. They're useful for crypto
applications where numbers are known to be of moderate size and where
low code
Ciao,
Il Lun, 4 Marzo 2013 7:41 pm, Richard Henderson ha scritto:
gmp-rename.h: gen-rename.c gen-rename.awk gmp.h
$(COMPILE) -E $ | $(AWK) -f $(srcdir)/gen-rename.awk $@ || (rm
+gmp-renamei.h: gen-renamei.c gen-rename.awk gmp.h gmp-impl.h
+ $(COMPILE) -E $ | $(AWK) -f
Ciao,
Il Gio, 7 Marzo 2013 9:14 pm, Torbjorn Granlund ha scritto:
romes p romes_12...@yahoo.com writes:
http:/www.hpcs.cs.tsukuba.ac.jp/~nakayama/cump/
Sheesh, the guy has copyied and edited the GMP webpages and now claims
the default all rights reserved with himself as owner. Not a
Ciao,
Il Lun, 18 Marzo 2013 12:05 pm, Torbjorn Granlund ha scritto:
Zimmermann Paul paul.zimmerm...@inria.fr writes:
indeed this is inconsistent. mpf_fits_uint_p(-0.5) should return true,
as well
as mpf_fits_uint_p(-0.999).
I am not so sure that would be the right fix here.
Do
Ciao,
Il Mar, 19 Marzo 2013 12:15 pm, Vincent Lefevre ha scritto:
On 2013-03-19 11:59:17 +0100, Torbjorn Granlund wrote:
We need to decide how to define the edge conditions.
We could either see at as can be assigned to type without havoc or is
in the range of type (or perhaps something other
Ciao,
Il Mar, 19 Marzo 2013 6:39 pm, Torbjorn Granlund ha scritto:
After some thought, I support I agree.
_fits_uTYPE require the range 0 = x uTYPE_MAX + 1
Which deviates.
One we agree, it is simple to obtain the desired range, swaping two
conditions...
--
http://bodrato.it/papers/
Ciao,
Il Gio, 29 Agosto 2013 6:06 pm, Torbjorn Granlund ha scritto:
Why do we call mpn_mul, mpn_mul_n, and mpn_sqr in the bnm1 functions'
basecases?
I'd say we should call mpn_mul_basecase and mpn_sqr_basecase instead,
for a few cycles less overhead.
It seems MUL_TOOM22_THRESHOLD
Ciao,
Il Ven, 27 Dicembre 2013 12:53 am, Torbjorn Granlund ha scritto:
I realise that this will be asymptotically slower, in this setting
O(n^3) vs O(n^2), but it ought have a much lower constant factor.
We will introduce a side-channel silent threshold...
Regards,
m
--
http://bodrato.it/
Ciao,
Looking at
https://gmplib.org/devel/lcov/shell/gmp/mpn/sec_powm.c.gcov.html
I saw that the function mpn_sec_powm_itch() is called twice for each
mpn_sec_powm(). This depends (I assume) because of the multiple evaluation
in the macro TMP_ALLOC_LIMBS (n + mpn_sec_powm_itch (bn, en, n));
in
Ciao,
Il Mar, 21 Gennaio 2014 4:24 pm, Torbjorn Granlund ha scritto:
Zimmermann Paul paul.zimmerm...@inria.fr writes:
Seed GMP_CHECK_RANDOMIZE=1391280408 (include this in bug reports)
repl-vsnprintf.c:379: GNU MP assertion failed: len total_width
/bin/bash: line 5: 7656 Aborted
Ciao,
Il Mer, 22 Gennaio 2014 12:44 pm, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
Maybe our printf/repl-vsnprintf.c is not tested enough?
Oddly enough it is not even listed at e.g.,
https://gmplib.org/devel/lcov/hannahnbsd32v61/gmp/printf/index.html.
Well, it is
Ciao,
Il Gio, 23 Gennaio 2014 8:39 am, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
Well, it is wrapped with
#if ! HAVE_VSNPRINTF /* only need this file if we don't have vsnprintf
so, on many systems it is not compiled at all... (and that's a reason
By forcing
Ciao,
Il Sab, 25 Gennaio 2014 7:15 pm, Torbjorn Granlund ha scritto:
operating system support. Now, we suppress use of (some) gcc
sse-related options which trigger bad behaviour (via the acinclude.m4
GMP_GCC_PENTIUM4_SSE2) and in that context check of the OS handles XMM
(via GMP_OS_X86_XMM).
Ciao,
Il Gio, 6 Febbraio 2014 2:08 pm, Niels ha scritto:
Personally, I feel a bit easier about adding feature close to release,
than about rewriting code for existing features.
So, maybe we can discuss about adding a new function to the _limbs interface:
mp_ptr
mpz_init_limbs_write (mpz_t x,
Ciao,
Il Gio, 6 Febbraio 2014 9:56 am, Niels ha scritto:
What do you think?
void
mpz_set_d (mpz_ptr r, double d)
{
int negative;
! mp_limb_t tp[MPN_SET_D_SIZE];
! mpz_t t = MPZ_ROINIT_N (tp, MPN_SET_D_SIZE);
Uhm, in tests/mpz/t-limbs.c we test MPZ_ROINIT_N only
#if
Ciao,
Il Sab, 8 Febbraio 2014 9:50 am, Niels ha scritto:
bodr...@mail.dm.unipi.it writes:
So, maybe we can discuss about adding a new function to the _limbs
interface:
mp_ptr
mpz_init_limbs_write (mpz_t x, mp_size_t n)
What is this intended for? Looks a bit like like mpz_init2.
Should we add to the documentation of
mpz_roinit_n (mpz_t x, const mp_limb_t *xp, mp_size_t xs)
that the array pointed by xp must have at least a readable limb even if
xs==0?
Regards,
m
--
http://bodrato.it/papers/
___
gmp-devel mailing list
{ap,an} and {bp,bn} where an = bn.
Or more accurately, bn = an 2bn.
Contributed to the GNU project by Marco Bodrato.
This code is dedicated to Buvik.
Copyright 2014 Free Software Foundation, Inc.
This code is free software; you can redistribute it and/or modify it
under the terms
Ciao,
Il Sab, 15 Febbraio 2014 4:55 pm, Torbjorn Granlund ha scritto:
I traced it to a nn=0 call to the underlying pi1 call. Dunno if that's
problematic.
Yes, that's the problem. When n=1.
Code says:
if (d GMP_NUMB_HIGHBIT)
{ /* Normalized case */
uh = up[--n]; /* Here n goes
Ciao,
Il Dom, 16 Febbraio 2014 5:45 pm, Torbjorn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
I disallowed zero DIV_QR_1_NORM_THRESHOLD with this patch:
Since we control these thresholds at the source level, if it is
desirable to keep DIV_QR_1_UNNORM_THRESHOLD = 1, that should be
Ciao
Il Lun, 17 Febbraio 2014 9:12 am, Niels ha scritto:
(on tuning of DIV_QR_1_UNNORM_THRESHOLD)
Me too, I checked how tuneup interacts with the current div_qr_1 code. You
are right, it seems the current code is OK. Good!
Regards,
m
--
http://bodrato.it/
Ciao,
Il Sab, 22 Febbraio 2014 7:46 am, Niels ha scritto:
I had a look at the new mpn_sqrtrem function in mini-gmp. Nice and
The docs says that the result area is ceil(n/2) limbs. Is it possible
that the top limb can be zero? If so, the code omits writing the leading
Let x = ceil(n/2), then
Ciao,
Il Mer, 15 Gennaio 2014 11:23 pm, Niels ha scritto:
Zimmermann Paul paul.zimmerm...@inria.fr writes:
Changes in mini-gmp.h: I had to add the following:
#define __GNU_MP_VERSION5
#define __GNU_MP_VERSION_MINOR 1
#define __GNU_MP_VERSION_PATCHLEVEL 3
One might argue
Ciao,
Il Ven, 17 Gennaio 2014 1:10 pm, Vincent Lefevre ha scritto:
you may also have optimizations based on the fact that some variable
cannot be zero. But you have no types that don't include zero. The
right solution is to make sure that the compiler knows the range.
#define HINT(expr)
Ciao,
Il Lun, 3 Marzo 2014 11:08 pm, Torbjorn Granlund ha scritto:
ni...@lysator.liu.se (Niels Möller) writes:
It seems mpz_probably_prime_p considers negated primes to also be prime.
I agree they are.
On rings I usually take the following definition for primes:
p is prime if and only if p
Ciao,
Il Gio, 6 Marzo 2014 7:07 pm, Niels ha scritto:
I agree with your analysis: with the suggested change the same answer is
given. Earlier, at no extra cost, I say.
I think there's some value in using precisely the same tests as in
standard text books, and that it's a very unlikely case
Ciao,
Il Mer, 5 Marzo 2014 6:07 pm, Niels ha scritto:
Maybe it's good enough to stop the base loop when we get a = n-1, even
if the caller specifies a large reps.
I changed the check_small function in the mini-gmp/tests/t-pprime_p.c file
you just pushed to:
for (i = 0; i 25005200; i++)
Ciao,
Il Mer, 23 Aprile 2014 11:36 am, Torbjörn Granlund ha scritto:
I was aware of that gcc recommends GMP 4.3.2, but not the full extent of
this their recommending. Why 5.1.1 is also popular is harder to guess.
(The 4 year old 4.3.2 is at least the last in a series, the 2nd most
popular
Dear developers,
Playing with https://gmplib.org/devel/lcov/ , I realised that many
branches of the mpf_ui_sub code was unused. Then I tried to improve the
test-suite...
Now the problem is: what do we want (and should we test) from mpf functions?
The manual [
Ciao,
Il Lun, 2 Giugno 2014 10:04 am, Andreas Enge ha scritto:
On Sun, Jun 01, 2014 at 08:20:19AM +0200, bodr...@mail.dm.unipi.it wrote:
Now the problem is: what do we want (and should we test) from mpf
functions?
Instead of re-implementing mpfr, an easy fix would be to simply drop mpf
Ciao,
I removed some code from mpn_perfpow, because it did the same job of the
more carefully refined mpn_remove function.
I measured a 5% speed-up with
$ time tests/mpz/t-perfpow 1
Moreover
$ valgrind tests/mpz/t-perfpow 1
says that also the total memory allocated is smaller with the
Ciao,
Il Lun, 1 Settembre 2014 2:40 pm, Torbjörn Granlund ha scritto:
ni...@lysator.liu.se (Niels Möller) writes:
examined number, the exponent is returned as mp_bitcnt_t, the returned
value is then casted to mp_limb_t, because we need the GCD of the
exponents and mpn_gcd_1 wants
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
Ciao Paul,
Il Lun, 27 Aprile 2015 4:37 pm, paul zimmermann ha scritto:
Please tell me if you find a faster version of the code.
Using tune/speed, the current code in GMP seems faster than the .c code
you published. But this does not mean that the algorithm is faster.
It depends, I suppose, on
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
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_1 (tp +
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 not
Ciao,
Il Mer, 5 Novembre 2014 11:36 pm, Torbjörn Granlund ha scritto:
t...@gmplib.org (Torbjörn Granlund) writes:
I decided to test running the nightly GMP runs under valgrind. We've
Time for some conclusions.
To be honest, our test-suite is not Valgrind-ready, but the opposite...
Many
Ciao,
Il Mar, 9 Giugno 2015 7:02 pm, Torbjörn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
We should probably use sqr whenever possible, perhaps it is worth having
a condition for this in rootrem.c, (I believe mpn_pow_1 gets it right,
and uses sqr whenever possible, since I looked
and Torbjorn Granlund (implementation).
Marco Bodrato specialised mpn_sqrtrem_internal for square roots.
THE FUNCTIONS IN THIS FILE ARE INTERNAL, AND HAVE MUTABLE INTERFACES. IT'S
ONLY SAFE TO REACH THEM THROUGH DOCUMENTED INTERFACES. IN FACT, IT'S ALMOST
GUARANTEED THAT THEY'LL CHANGE
Ciao,
Il Lun, 8 Giugno 2015 10:15 am, Torbjörn Granlund ha scritto:
I played some years ago with a loop computing A^(-0.5), which naturally
becomes division-free. An alternative would be to keep the current
algorithm, but use the fact that the previous divisor is a damn good
staring
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 Dom, 21 Giugno 2015 2:43 pm, Torbjörn Granlund ha scritto:
ni...@lysator.liu.se (Niels Möller) writes:
As far as I understand, it would typically affect only assembly code
(which is supposedly well tested and not subject to compiler bugs). But
if the fat machinery selects
Ciao,
Il Mer, 24 Giugno 2015 9:56 am, Torbjörn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
As the manual says about low-level functions: No size argument may be
zero.
That certainly isn't true in general, at least not for the entire set of
mpn functions. I think it might be a
Ciao,
Il Mer, 24 Giugno 2015 12:00 pm, Torbjörn Granlund ha scritto:
polished. What about this initial patch:
--- gmp-main/mpn/x86_64/fastsse/com.asm Wed Jun 24 11:59:18 2015
***
*** 79,85
FUNC_ENTRY(3)
- testn, n
- jz L(don)
-
Agreed.
Ciao,
Il Ven, 12 Giugno 2015 9:04 am, Torbjörn Granlund ha scritto:
We might want to look into the plain division-free sqrt(A) = A*sqrt(1/A)
approach before implementing a tricky division sqrt(A).
We can try improving the current implementation, before implementing any
other algorithm :-)
I
Il Sab, 13 Giugno 2015 12:27 am, bodr...@mail.dm.unipi.it ha scritto:
I wrote a simple patch (it touches very few lines) that allows
skippingthe final
I forgot the attachment...
--
http://bodrato.it/
gmp.diff
Description: plain/text
___
gmp-devel
Ciao,
Il Dom, 21 Giugno 2015 10:12 pm, Torbjörn Granlund ha scritto:
I am finally doing something about hiding internal GMP symbols for
the shared gmplib.{so,lib,dll}.
Great!
The good effects of this are:
1. The symbols cannot be reached from outside of the shared lib.
2. The internal
Ciao,
Il Mer, 24 Giugno 2015 10:25 pm, Niels Möller ha scritto:
bodr...@mail.dm.unipi.it writes:
If we need both the sqrt of the high-half and the residual, we should
directly use sqrtrem, don't we?
Maybe, but it's not obvious. For simplicity, consider the case of
smallish numbers, so we
Ciao,
Il Mer, 24 Giugno 2015 10:48 am, bodr...@mail.dm.unipi.it ha scritto:
Il Mer, 10 Giugno 2015 9:54 pm, Niels Möller ha scritto:
And the divisions really ought to use divappr, rather than exact
truncating division.
You are right, I did not try divappr yet. I'll do.
Using div_q (not
Ciao,
Il Mer, 24 Giugno 2015 9:53 am, Torbjörn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
But the code I'm experimenting with is not ready yet, it supports only
even sizes currently.
That's another 10% speedup.
Yes... unluckily I did not have the time to adapt it to odd
Il Gio, 21 Maggio 2015 10:08 pm, Niels Möller ha scritto:
t...@gmplib.org (Torbjörn Granlund) writes:
GMP triggers bugs in clang on every platform where we tried this
compiler.
It looks like it almost works on x86, except for failures with the
(obscure?) x32 ABI.
Do we have any working
Ciao,
Il Lun, 6 Luglio 2015 11:46 pm, Torbjörn Granlund ha scritto:
Unfortunately, it has now become obvious to me that symbol hiding
conflicts with unit testing. :-(
This can be handled either by
1. hiding (much!) fewer internal symbols, or by
I agree with starting to hide some symbols.
Ciao,
Il Lun, 6 Luglio 2015 11:28 pm, Torbjörn Granlund ha scritto:
bodr...@mail.dm.unipi.it writes:
... yes, I know, we really need to improve also odd sizes...
Perhaps one could simply wrap the current function in code which appends
a zero limbs, calls the current code, and then
1 - 100 of 438 matches
Mail list logo
