On Sat, 9 Jun 2012, bodr...@mail.dm.unipi.it wrote:
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
"It is important to understand that your program can copy around
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.uninitva
On Fri, 8 Jun 2012, bodr...@mail.dm.unipi.it wrote:
Ciao,
Il Sab, 2 Giugno 2012 9:21 pm, bodr...@mail.dm.unipi.it ha scritto:
"mark" the possible uses with a different macro. So that we can count how
many times, and see where, we might need the no-copy-realloc.
Macro created, nothing changed
Ciao,
Il Sab, 2 Giugno 2012 9:21 pm, bodr...@mail.dm.unipi.it ha scritto:
> "mark" the possible uses with a different macro. So that we can count how
> many times, and see where, we might need the no-copy-realloc.
Macro created, nothing changed in the library, unless we WANT_ASSERT.
--
http://b
Ciao,
Il Mar, 5 Giugno 2012 11:34 pm, Torbjorn Granlund ha scritto:
> 1. mpz_pprime_p, for doing some trial dividing and unspecified
>probabilistic primality tests to specified probability.
I'd like to keep the "Return 2 if n is definitely prime" feature of the
current _probab_prime_ function
What I think is unacceptable is that if a composite passes the test, it
also passes the test when invoked a second time because the bases it's
tested against are always the same. That's the why of a version that
accepts a random state. So, a new function is recommendable in any case.
T
Marc Glisse writes:
> On Mon, 4 Jun 2012, Niels Möller wrote:
>
>> (but I'm not sure I'd trust the automatic stack unwinding with C++
>> exceptions either...).
>
> Why not?
*Maybe* I'd trust it if I knew better how it works. I don't have much
experience in C++.
My understanding is that it's ver
On Mon, 4 Jun 2012, Niels Möller wrote:
(but I'm not sure I'd trust the automatic stack unwinding with C++
exceptions either...).
Why not?
It does require rewriting a few things in a more C++ way, so cleanup is
done by a destructor, but at least all the places where we use macros can
be han
ni...@lysator.liu.se (Niels Möller) writes:
Torbjorn Granlund writes:
> I know of only two C mechanims, either signals+handlers or setjmp+
> longjmp.
I'm not entirely sure what type of errors you are considering handling
here? Memory allocation failures? Divide-by-zero? Something
Torbjorn Granlund writes:
> I know of only two C mechanims, either signals+handlers or setjmp+
> longjmp.
I'm not entirely sure what type of errors you are considering handling
here? Memory allocation failures? Divide-by-zero? Something else?
It's possible to make errno-style handling thread sa
On Mon, 4 Jun 2012, Torbjorn Granlund wrote:
Pedro Gimeno writes:
My recollection is that gmp_errno was not thread-safe, not just
obsolete, and that that was a reason for getting rid of it.
If the main issue with gmp_errno is thread-safety, it should just become
thread-local, like the reg
Torbjorn Granlund writes:
> Last time you suggested this, I think I asked you to explain how to do
> with the multitude of multiply functions, which might need to store the
> full n-limb value in a new large temp area, then copy its low n-1 limbs
> to the target area.
One would have to convert t
bodr...@mail.dm.unipi.it wrote:
> IIRC someone proposed to change the meaning of the second argument of
> mpz_probab_prime_p. Now it is documented as "reps controls how many
> [Miller-Rabin] tests are done". It should be something like "logprob
> controls the likeliness of a wrong answer, the func
I've seen attempts at structured exception handling in C using
setjmp/longjmp but they looked awkward and were incomplete, so SEH might
not be the way to go in C. I don't know what other options may exist.
I know of only two C mechanims, either signals+handlers or setjmp+
longjmp. Using s
Torbjorn Granlund wrote:
> Pedro Gimeno writes:
>
> My recollection is that gmp_errno was not thread-safe, not just
> obsolete, and that that was a reason for getting rid of it.
>
> Making some C error handling mechanism would be great, though. I am not
> sure that's easy, though. "For e
ni...@lysator.liu.se (Niels Möller) writes:
The old_size argument should be removed also from the free function, not
just realloc.
Fixed.
Add return value to mpz_sqrt, for consistency with mpz_root (assuming
such a flag can be returned very cheaply, which I think it can).
Added.
bodr...@mail.dm.unipi.it writes:
IIRC someone proposed to change the meaning of the second argument of
mpz_probab_prime_p. Now it is documented as "reps controls how many
[Miller-Rabin] tests are done". It should be something like "logprob
controls the likeliness of a wrong answer, the fun
Ciao,
Il Lun, 4 Giugno 2012 6:32 pm, Torbjorn Granlund ha scritto:
> Pedro Gimeno 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 random state. Of cour
Pedro Gimeno writes:
My recollection is that gmp_errno was not thread-safe, not just
obsolete, and that that was a reason for getting rid of it.
Making some C error handling mechanism would be great, though. I am not
sure that's easy, though. "For error handling, use C++"?
Also, I see
Torbjorn Granlund wrote:
> I started a page: http://gmplib.org/devel/incompatibility.html
>
> We might want to classify incompatibilities as source, binary, and both.
>
> I have not listed obsolete functions. The cost of retaining obsolete
> function compatibility is very low; the temptation to
Marc Glisse writes:
Naive question:
are there many ABIs where adding a return type breaks compatibility?
Probably few. But it breaks source code compatibility, if it is called
via a typed function pointer. Our own tests/mpz/reuse.c would need
modifications...
--
Torbjörn
On Sun, 3 Jun 2012, Niels Möller wrote:
Add return value to mpz_sqrt, for consistency with mpz_root (assuming
such a flag can be returned very cheaply, which I think it can).
Naive question:
are there many ABIs where adding a return type breaks compatibility?
--
Marc Glisse
__
Torbjorn Granlund writes:
> I started a page: http://gmplib.org/devel/incompatibility.html
The old_size argument should be removed also from the free function, not
just realloc.
Add return value to mpz_sqrt, for consistency with mpz_root (assuming
such a flag can be returned very cheaply, which
ni...@lysator.liu.se (Niels Möller) writes:
The point, as I understand it, is to collect various problems where the
fixes imply interface changes, and which hence are not going to happen
in any release currently planned. So we don't forget them, if/when we
ever to planning a release which
bodr...@mail.dm.unipi.it writes:
> Only the second one is needed. Things that all developers think are broken
> should be included in the page "planned improvements".
The point, as I understand it, is to collect various problems where the
fixes imply interface changes, and which hence are not goi
Ciao,
Il Sab, 2 Giugno 2012 6:32 pm, Niels Möller ha scritto:
> Torbjorn Granlund 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 library,
Torbjorn Granlund writes:
> I thought avoiding the copying was a good idea, but this thread has made
> me less sure. I suppose it will speed things up only for sizes > some
> threshold, else slow things down.
I guess some benchmarks are needed here.
> It is a shame that C provides such primiti
I thought avoiding the copying was a good idea, but this thread has made
me less sure. I suppose it will speed things up only for sizes > some
threshold, else slow things down.
If we follow the GMP principle of relative overhead, perhaps we should
not do this.
It is a shame that C provides such
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 requ
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
it (I know this is a chicken and egg thing...). By "conservative", do
bodr...@mail.dm.unipi.it writes:
> I know there are other arguments, we might discuss about a possible change
> in the memory interface. The points I see:
>
> - should we ask for a fourth function (alloc, free, conservative_realloc,
> nonconservative_realloc)?
Maybe. If anyone has the time for th
Ciao,
Il Gio, 31 Maggio 2012 3:25 pm, Marc Glisse ha scritto:
> On Thu, 31 May 2012, Niels Möller wrote:
>> And then the question remains, are there systems and C libraries where
>> free + malloc is significantly slower than realloc in common cases?
>
> I am afraid so. Experiments are needed, but
On Thu, 31 May 2012, Niels Möller wrote:
bodr...@mail.dm.unipi.it writes:
Do you mind if I define a new macro MPZ_NEWALLOC?
Currently it should be the same as MPZ_REALLOC, but it can be changed in
the future...
To me it would make some sense to make it do something useful right
away...
Ass
bodr...@mail.dm.unipi.it writes:
> Do you mind if I define a new macro MPZ_NEWALLOC?
> Currently it should be the same as MPZ_REALLOC, but it can be changed in
> the future...
To me it would make some sense to make it do something useful right
away...
You'd also need a corresponding function _mp
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
bodr...@mail.dm.unipi.it writes:
> Inspired from mpz/mul.c... Maybe we can write a macro based on:
>
> (*__gmp_free_func) (PTR(x), ALLOC (x) * BYTES_PER_MP_LIMB);
> ALLOC (x) = newsize;
> PTR(x) = (mp_ptr) (*__gmp_allocate_func) (newsize * BYTES_PER_MP_LIMB);
That's going to be more expensive in
bodr...@mail.dm.unipi.it writes:
Inspired from mpz/mul.c... Maybe we can write a macro based on:
(*__gmp_free_func) (PTR(x), ALLOC (x) * BYTES_PER_MP_LIMB);
ALLOC (x) = newsize;
PTR(x) = (mp_ptr) (*__gmp_allocate_func) (newsize * BYTES_PER_MP_LIMB);
That's another possibility.
--
T
Ciao,
Il Ven, 24 Febbraio 2012 11:32 am, Torbjorn Granlund ha scritto:
> bodr...@mail.dm.unipi.it writes:
> I always used the MPZ_REALLOC macro, to enlarge (if needed) the memory
> area available for an integer. This macro gives a (possibly new) pointer
> with the requested size available...
bodr...@mail.dm.unipi.it writes:
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 c
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
ni...@lysator.liu.se (Niels Möller) writes:
What about the test in
#define TMP_ALLOC(n) \
(LIKELY ((n) < 65536) ? TMP_SALLOC(n) : TMP_BALLOC(n))
That test will cost a cycle or two for each TMP_ALLOC call (with
non-constant n), regardless of size, won't it?
I think my previous
Torbjorn Granlund writes:
> I think the conclusion is that TMP_ALLOC_LIMBS_2 could save some cycles
> by collapsing two malloc calls into one, when allocating large blocks
> using TMP_ALLOC (as opposed to TMP_BALLOC or TMP_SALLOC).
What about the test in
#define TMP_ALLOC(n) \
(LIKELY ((n) <
ni...@lysator.liu.se (Niels Möller) writes:
Torbjorn Granlund writes:
> Surely a plain TMP_ALLOC adds red zones? If not, that is something we
> ought to fix.
But
tp = TMP_ALLOC_LIMBS (2*n);
xp = tp + n;
does not add any between T and X (intended to hold n limbs each
Torbjorn Granlund writes:
> Surely a plain TMP_ALLOC adds red zones? If not, that is something we
> ought to fix.
But
tp = TMP_ALLOC_LIMBS (2*n);
xp = tp + n;
does not add any between T and X (intended to hold n limbs each). So if
one doesn't use TMP_ALLOC_LIMBS_2, one should instead writ
Sorry, I sent the previous mail by mistake...
--
http://bodrato.it/
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
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 t
Marc Glisse writes:
That's for the alloca case. Without alloca, one call to malloc is
better than two (although that usually also means the numbers are big
and any gmp operation will dwarf allocation). Also, the threshold
between alloca and malloc is quite high, and with many separate
a
On Wed, 22 Feb 2012, Torbjorn Granlund wrote:
bodr...@mail.dm.unipi.it writes:
Unrelated :-) We might define more macros like TMP_ALLOC_LIMBS_2 . I mean
_3 and _4. So that they can be used to reduce the number of allocations.
Do you agree? (I just touched mpz/gcdext.c, and _4 should be used
ni...@lysator.liu.se (Niels Möller) writes:
Torbjorn Granlund writes:
> TMP_ALLOC_LIMBS_2 is clutter IMHO.
Sure, it's pointless in a normal build.
As I understand it, the reason for having TMP_ALLOC_LIMBS_2 is to make
--enable-alloca=debug more effective, by getting some kind o
Torbjorn Granlund writes:
> TMP_ALLOC_LIMBS_2 is clutter IMHO.
Sure, it's pointless in a normal build.
As I understand it, the reason for having TMP_ALLOC_LIMBS_2 is to make
--enable-alloca=debug more effective, by getting some kind of red zone
separating the two areas. Whether or not that's wo
bodr...@mail.dm.unipi.it writes:
Unrelated :-) We might define more macros like TMP_ALLOC_LIMBS_2 . I mean
_3 and _4. So that they can be used to reduce the number of allocations.
Do you agree? (I just touched mpz/gcdext.c, and _4 should be used there).
I'd vote for killing TMP_ALLOC_LIMB
Ciao,
Il Mer, 22 Febbraio 2012 7:41 pm, Torbjorn Granlund ha scritto:
> Marc Glisse 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 this. The macro LI
Marc Glisse writes:
is there any objection if I replace most uses of ->_mp_alloc by calls
to the ALLOC macro in mp[zqf] (and similarly for _mp_size, etc)? It
helps when experimenting... I am also considering moving the NUM and
DEN macros from test/mpq/t-cmp* to gmp-impl.h, since I assume
Hello,
is there any objection if I replace most uses of ->_mp_alloc by calls to
the ALLOC macro in mp[zqf] (and similarly for _mp_size, etc)? It helps
when experimenting... I am also considering moving the NUM and DEN macros
from test/mpq/t-cmp* to gmp-impl.h, since I assume mpq_numref and
mp
54 matches
Mail list logo
