Re: Lazy mpz allocation

On 2018-04-20 18:29:55 +0200, Trevor Spiteri wrote: > >>> Only 0 can have lazy allocation, and I think we document that it isn't > >>> legal to put 0 on the denominator. > >> where is this documented? > > That was in a "I think" sentence. Now that I looked a bit more, I don't > > find it... Well,

Re: Lazy mpz allocation

>>> Only 0 can have lazy allocation, and I think we document that it isn't >>> legal to put 0 on the denominator. >> where is this documented? > That was in a "I think" sentence. Now that I looked a bit more, I don't > find it... Well, you can't call any mpq function that reads that mpq_t, > but

Re: Lazy mpz allocation

On Fri, 20 Apr 2018, paul zimmermann wrote: Only 0 can have lazy allocation, and I think we document that it isn't legal to put 0 on the denominator. where is this documented? That was in a "I think" sentence. Now that I looked a bit more, I don't find it... Well, you can't call any mpq

Re: Lazy mpz allocation

> Only 0 can have lazy allocation, and I think we document that it isn't > legal to put 0 on the denominator. where is this documented? In mpfr_set_q we use the fact that the user can set q to 1/0 for example to represent +Inf. Paul ___ gmp-devel

Re: Lazy mpz allocation

On Fri, 20 Apr 2018, Marco Bodrato wrote: Ciao, Il Gio, 19 Aprile 2018 4:37 pm, Marc Glisse ha scritto: I finally pushed it. It seemed unsafe to keep mpq unaware of lazy allocation, in case people start swapping the numerator of a rational with a lazy 0 integer or something like that. If we

Re: Lazy mpz allocation

Ciao, Il Gio, 19 Aprile 2018 4:37 pm, Marc Glisse ha scritto: > I finally pushed it. It seemed unsafe to keep mpq unaware of lazy > allocation, in case people start swapping the numerator of a rational with > a lazy 0 integer or something like that. If we fear swaps, then ... what about swapping

Re: Lazy mpz allocation

On Mon, 11 Apr 2016, Marc Glisse wrote: On Mon, 9 Nov 2015, Marco Bodrato wrote: Moreover, the mpq layer and mini-gmp need to migrate to lazy allocation too... For mpq, the attached seems sufficient to pass make check. I finally pushed it. It seemed unsafe to keep mpq unaware of lazy

Re: Lazy mpz allocation

On Wed, 4 May 2016, Niels Möller wrote: Marc Glisse writes: The fact that an mpq is made of 2 mpz that can be accessed directly is part of the interface. I think following your suggestion would mean changing that. I guess you're right, it would break mpq_denref. Which

Re: Lazy mpz allocation

On Wed, 4 May 2016, Niels Möller wrote: t...@gmplib.org (Torbjörn Granlund) writes: I forgot about that we need to have an explicit denominator. We could surely point that to some static read-only data, but that would of course incur a cost when "re-allocating". I'm not familiar with mpq

Re: Lazy mpz allocation

t...@gmplib.org (Torbjörn Granlund) writes: > I forgot about that we need to have an explicit denominator. > We could surely point that to some static read-only data, but that would > of course incur a cost when "re-allocating". I'm not familiar with mpq internals, but I guess it might be

Re: Lazy mpz allocation

On Mon, 9 Nov 2015, Marco Bodrato wrote: Moreover, the mpq layer and mini-gmp need to migrate to lazy allocation too... For mpq, the attached seems sufficient to pass make check. Of course, without a copy-on-write mechanism for the 1 in the denominator, the gains are not comparable to the

Re: Lazy mpz allocation

Marc Glisse writes: the function mpz_init could now be marked __GMP_NOTHROW. Do we want to do it? I could then propagate the change to the C++ wrapper, which would have a significant impact on the performance of std::vector for instance. On the other hand, this is a

Re: Lazy mpz allocation

Hello, the function mpz_init could now be marked __GMP_NOTHROW. Do we want to do it? I could then propagate the change to the C++ wrapper, which would have a significant impact on the performance of std::vector for instance. On the other hand, this is a promise in the interface, going back

Re: Lazy mpz allocation

Ciao, Il Lun, 9 Novembre 2015 8:36 pm, Niels Möller ha scritto: > I agree on the direction. Please do it! Done: https://gmplib.org/repo/gmp/rev/299ec6187305 Of course you may have better suggestions for mpz/init*.c (currently there are different dummy_limbs, all defined inside their own init

Re: Lazy mpz allocation

"Marco Bodrato" writes: > Moreover, the mpq layer and mini-gmp need to migrate to lazy allocation > too... As for mini-gmp, there's no user visible interface change yet, right? So not urgent, even if for consistency it would make sense to to it in the same way there.

Re: Lazy mpz allocation

Ciao, Il Lun, 28 Settembre 2015 10:26 am, Torbjörn Granlund ha scritto: > Some weeks ago, I made a naive testsuite-driven attempt at implementing > lazy allocation. I had 55 FAILures and 114 PASSes after having fixed > these files: > > M mpz/clear.c > M mpz/clears.c > M mpz/init.c > M mpz/mul.c

Re: Lazy mpz allocation

"Marco Bodrato" writes: > If we agree with moving towards lazy allocation, I'll commit the changes. > So that we start testing early! I agree on the direction. Please do it! Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet

Re: Lazy mpz allocation

"Marco Bodrato" writes: I looked into the code and realised that my proposal requires an MPZ_REALLOC or if(ALLOC(x)==0) branch in ANY place where we write into an mpz_t. E.g. mpz_combit starts with: if (limb_index + 1 < SIZ(x)) { PTR(x)[limb_index] ^=

Re: Lazy mpz allocation

"Marco Bodrato" writes: >> I'd like a sort of "copy-on-write" interface, that allocates the needed > > I looked into the code and realised that my proposal requires an > MPZ_REALLOC or if(ALLOC(x)==0) branch in ANY place where we write into an > mpz_t. E.g. mpz_combit

Re: Lazy mpz allocation

Ciao, Il Mar, 1 Settembre 2015 6:46 am, Marco Bodrato ha scritto: > I think that the condition to distinguish mpzs that where not allocated > yet should be ALLOC(x)==0. As a consequence, MPZ_ROINIT_N can be the > interface for initialising you ask for. > I'd like a sort of "copy-on-write"

Shared lib symbol hiding (Was: Re: Lazy mpz allocation)

"Marco Bodrato" writes: You pushed a patch to check if both 'attribute ((visibility ("hidden")))' and '__attribute__ ((alias...' are available. Maybe in some cases (e.g. the constant limb we are speaking about in this thread) we only want to hide, without the

Re: Lazy mpz allocation

Ciao, Il Lun, 31 Agosto 2015 6:27 pm, Torbjörn Granlund ha scritto: > (We should use 'attribute ((visibility ("hidden")))' for the the constant > zero limbs at any rate. I'll commit a basic patch for that soonish.) You pushed a patch to check if both 'attribute ((visibility ("hidden")))' and

Re: Shared lib symbol hiding (Was: Re: Lazy mpz allocation)

Ciao, Il Lun, 7 Settembre 2015 5:34 pm, Torbjörn Granlund ha scritto: > "Marco Bodrato" writes: > Maybe in some cases (e.g. the constant limb we are speaking about in > this thread) we only want to hide, without the need of an alias? > > We could separate them. We

Re: Lazy mpz allocation

ni...@lysator.liu.se (Niels Möller) writes: Sure, but we could do static const mp_limb_t dummy_limb = 0xc0dedead; void mpz_init (mpz_t x) { x->_mp_size = x->_mp_alloc = 0; x->_mp_d = _limb; } It still represents the number zero, it's just that _mp_d[0]

Re: Lazy mpz allocation

t...@gmplib.org (Torbjörn Granlund) writes: > "Marco Bodrato" writes: > > If we change (I'd agree) mpz_init into > > void > mpz_init (mpz_ptr x) > { > ALLOC (x) = 0; /* ZERO, any MPZ_REALLOC will allocate */ > PTR (x) = &

Re: Lazy mpz allocation

t...@gmplib.org (Torbjörn Granlund) writes: > (We should use 'attribute ((visibility ("hidden")))' for the the > constant zero limbs at any rate. I'll commit a basic patch for that > soonish.) Maybe it should have a more interesting value than zero, to help catch bugs if it is used when it

Re: Lazy mpz allocation

ni...@lysator.liu.se (Niels Möller) writes: t...@gmplib.org (Torbjörn Granlund) writes: > (We should use 'attribute ((visibility ("hidden")))' for the the > constant zero limbs at any rate. I'll commit a basic patch for that > soonish.) Maybe it should have a more interesting

Re: Lazy mpz allocation

t...@gmplib.org (Torbjörn Granlund) writes: > Unfortunately, the manual sayd "Initialize x, and set its value to 0." > about mpz_init. Sure, but we could do static const mp_limb_t dummy_limb = 0xc0dedead; void mpz_init (mpz_t x) { x->_mp_size = x->_mp_alloc = 0; x->_mp_d = _limb;

Lazy mpz allocation (Was: Re: mpq_cmp_z)

Marco Bodrato bodr...@mail.dm.unipi.it writes: If we change (I'd agree) mpz_init into void mpz_init (mpz_ptr x) { ALLOC (x) = 0; /* ZERO, any MPZ_REALLOC will allocate */ PTR (x) = static_const_limb_shared_by_all_instances; SIZ (x) = 0; } I suppose we should do this!