Re: _mp_alloc vs ALLOC
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 my intuition tells me that for > small numbers (for large numbers, the cost of copying in realloc is anyway > small compared to whatever operation you are doing), free+malloc will be > significantly slower than realloc. I renewed the question because I was looking into mpq. In almost all cases (mpq_abs, mpq_get_den, mpq_get_num, mpq_inv, mpq_neg, mpq_set, mpq_set_den, mpq_set_num, mpq_set_z) I touched, the "whatever" operation is a copy, and we risk to spend almost half of the total time in the copy implied by realloc. Of course, those functions are not the most time-critical ones... 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)? >> (Speaking of allocation, I also wonder what to do about the problem >> described in >> http://gmplib.org/list-archives/gmp-devel/2012-January/002161.html, >> there were no replies at the time). - should we keep the old_size parameter in the interface? > Related: I was always unhappy about the order of the reallocation function > arguments. malloc and free can be used by gmp (just ignore the old size > passed as last argument) but realloc needs a wrapper. - should we change the order of parameters? Best regards, Marco -- http://bodrato.it/papers/ ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP aborting in __gmpn_cpuvec_init when run inside KVM
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 Pentium II.
> By the way, it seems that Marco already removed the aborts a few days ago.
Right, the patches are published.
For the development branch: http://gmplib.org:8000/gmp/rev/e1f4512a775f
For the released library: http://gmplib.org:8000/gmp-5.0/rev/ffdad0cda019
After the patch, the library keeps on requiring that at least the "64-bit"
capability-bit is set, otherwise nothing reasonable can be done.
Regards,
Marco
--
http://bodrato.it/papers/
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP aborting in __gmpn_cpuvec_init when run inside KVM
Marc Glisse writes: And I couldn't see anything about the KVM folks refusing to fix something there or anywhere else google led me to. Maybe this choice of CPU has a desirable effect on windows or something, but I haven't managed to find the right page yet... By the way, it seems that Marco already removed the aborts a few days ago. Indeed he did, but he also inserted code for checking for 64-bit capability. I consider this as a reasonable workaround for incorrect behaviour in an emulator. We can afford to do this since cpuvec_init is not critical. -- Torbjörn ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP aborting in __gmpn_cpuvec_init when run inside KVM
On Thu, 31 May 2012, Richard Guenther wrote:
On Thu, 31 May 2012, Marc Glisse wrote:
On Thu, 31 May 2012, Richard Guenther wrote:
KVM unfortunately defaults to an impossible CPU model/family on x86_64
("GenuineIntel", family 6, model 2). This leads to
__gmpn_cpuvec_init abort()ing. Of course KVM is to blame here but
they appearantly don't want to fix ...
Do you have a link to the corresponding bug report / conversation?
https://bugzilla.novell.com/show_bug.cgi?id=671262
"You are not authorized to access bug #671262."
But it looks like the same info is on:
http://lists.opensuse.org/opensuse-bugs/2011-02/msg01800.html
and its various duplicates report GCC crashes because of this
when using in a virtualized 64bit environment. The KVM folks not
willing to fix things is is not direct information but from
conversation in that bug.
And I couldn't see anything about the KVM folks refusing to fix something
there or anywhere else google led me to. Maybe this choice of CPU has a
desirable effect on windows or something, but I haven't managed to find
the right page yet...
By the way, it seems that Marco already removed the aborts a few days ago.
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP aborting in __gmpn_cpuvec_init when run inside KVM
On Thu, 31 May 2012, Marc Glisse wrote:
> On Thu, 31 May 2012, Richard Guenther wrote:
>
> > KVM unfortunately defaults to an impossible CPU model/family on x86_64
> > ("GenuineIntel", family 6, model 2). This leads to
> > __gmpn_cpuvec_init abort()ing. Of course KVM is to blame here but
> > they appearantly don't want to fix ...
>
> Do you have a link to the corresponding bug report / conversation?
https://bugzilla.novell.com/show_bug.cgi?id=671262
and its various duplicates report GCC crashes because of this
when using in a virtualized 64bit environment. The KVM folks not
willing to fix things is is not direct information but from
conversation in that bug.
Googling also leads me to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671866
so we're not the only ones seeing this.
Richard.
--
Richard Guenther
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP aborting in __gmpn_cpuvec_init when run inside KVM
On Thu, 31 May 2012, Richard Guenther wrote:
KVM unfortunately defaults to an impossible CPU model/family on x86_64
("GenuineIntel", family 6, model 2). This leads to
__gmpn_cpuvec_init abort()ing. Of course KVM is to blame here but
they appearantly don't want to fix ...
Do you have a link to the corresponding bug report / conversation?
--
Marc Glisse
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
GMP aborting in __gmpn_cpuvec_init when run inside KVM
KVM unfortunately defaults to an impossible CPU model/family on x86_64
("GenuineIntel", family 6, model 2). This leads to
__gmpn_cpuvec_init abort()ing. Of course KVM is to blame here but
they appearantly don't want to fix ...
Now, libraries such as GMP should not call abort(), at least not if
they can do something reasonable - like in this case simply defaulting
to the default code-path.
So - can you please change all abort () calls in __gmpn_cpuvec_init
to break;
Thanks,
Richard.
--
Richard Guenther
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
Re: _mp_alloc vs ALLOC
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... Assuming we can... 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 my intuition tells me that for small numbers (for large numbers, the cost of copying in realloc is anyway small compared to whatever operation you are doing), free+malloc will be significantly slower than realloc. probably naïve, but if we consider the case that the current block can be easily extended in place, I imagine that free will put it at the head of the free list, and the subsequent call to malloc will get it back. Allocators often try to separate allocations depending on their size. They will try to respect a realloc call, but if they can (free+malloc) they may prefer taking a block from another pool. Letting them do it may be a good thing in the long run (less fragmentation, future allocations are faster), but may be slower for this particular call. Again, this is pure speculation, I may be way off. Then the additional overhead compared to realloc seems small, but I guess it could matter, e.g., if access to the free list is protected by a mutex. I don't think many allocators still do that... (Speaking of allocation, I also wonder what to do about the problem described in http://gmplib.org/list-archives/gmp-devel/2012-January/002161.html, there were no replies at the time). Good question ;-) Related: I was always unhappy about the order of the reallocation function arguments. malloc and free can be used by gmp (just ignore the old size passed as last argument) but realloc needs a wrapper. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: _mp_alloc vs ALLOC
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 _mpz_newalloc (if that's a good name?) which is almost identical to _mpz_realloc, but uses free + alloc rather than realloc. And then the question remains, are there systems and C libraries where free + malloc is significantly slower than realloc in common cases? I'm probably naïve, but if we consider the case that the current block can be easily extended in place, I imagine that free will put it at the head of the free list, and the subsequent call to malloc will get it back. Then the additional overhead compared to realloc seems small, but I guess it could matter, e.g., if access to the free list is protected by a mutex. (Speaking of allocation, I also wonder what to do about the problem described in http://gmplib.org/list-archives/gmp-devel/2012-January/002161.html, there were no replies at the time). Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: _mp_alloc vs ALLOC
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 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... but it also copies the content. > > Sometimes I know in advance that the content can be discarded. Is there > I use this trick for that: > > rp = realloc (rp, 1); > rp = realloc (rp, newsize); > > I suspect there is a lot to win from using such a trick, at least of the ... > I am not sure how to deal with this in GMP. We could add a flag field > in MPZ_REALLOC, or have special functions+macros. Most of the uses of MPZ_REALLOC in mpq don't need the data relocation at all, because the next step usually consists in overwriting them. 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... Regards, Marco PS: I'm also removing LIMBS from gmp-impl.h, an alias for PTR. -- http://bodrato.it/papers/ ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
