Re: Has there been historical work done to investigate small integer optimization?

On 2024-02-12 08:18:09 -0500, Stefan Koch wrote: > This was mostly my idea. I thought that if _mp_alloc was small enough (in > most cases 1), then instead of _mp_d being the pointer to the first lib it > was just the first limb. Note that the size of a limb may be larger than the size of a

Re: Has there been historical work done to investigate small integer optimization?

On 2024-02-12 13:01:45 +0100, Richard Biener wrote: > Oh, and _mp_alloc < 0 could also simply mean the allocation is > "inline", aka > > typedef struct > { > int _mp_alloc;/* Number of *limbs* allocated and pointed >to by the _mp_d field. */

Re: stdio.h

On 2022-08-22 14:17:08 +0200, Paul Zimmermann wrote: >Hi, > > the fine manual says: > >All declarations needed to use GMP are collected in the include file >'gmp.h'. It is designed to work with both C and C++ compilers. > > #include > > Note however that

Re: Risc V greatly underperforms

On 2021-09-20 11:53:13 +0200, Torbjorn Granlund wrote: > Let's look at some examples of how Risc V underperforms. First, > addition of a double-word integer with carry-out: > > add t0, a4, a6 // add low words > sltut6, t0, a4 // compute carry-out from low add >

Re: pointers vs arrays

On 2021-06-09 20:29:35 +0200, Marc Glisse wrote: > On Wed, 9 Jun 2021, Marco Bodrato wrote: > > By the way, I think that also the documentation should be updated > > accordingly. > > We have never documented mpz_ptr/mpz_srcptr, my patch does not change this > discrepancy. Maybe this is a new

Re: mini-gmp warnings

On 2020-04-26 14:31:21 +0200, Niels Möller wrote: > I'm updating the copy of mini-gmp I use in nettle to the latest version. > In Nettle, it's compiled with gcc -Wall, and I some new warnings, like > > /home/nisse/hack/nettle/mini-gmp.c: In function ‘mpn_common_scan’: >

Re: mini-gmp "bug" missing mpz_fits_sint_p / mpz_fits_uint_p

On 2020-04-20 15:25:54 +0200, Marco Bodrato wrote: > Ciao, > > Il 2020-04-20 11:08 Vincent Lefevre ha scritto: > > I think that in general, you should not write code that depends on > > whether INT_MAX + INT_MIN == 0 or not (the constant INT_MAX + INT_MIN > > might b

Re: mini-gmp "bug" missing mpz_fits_sint_p / mpz_fits_uint_p

On 2020-04-19 12:23:03 +0200, Niels Möller wrote: > >> BTW, do we have any C implementation where INT_MAX + INT_MIN == 0, > >> i.e., > >> not using two's complement? > > > > I'm almost sure the compiler can optimise that out at compile time. > > Agreed. But if we attempt to support non two's

Re: Funny clang behaviour

On 2020-02-18 16:04:54 +0100, Niels Möller wrote: > Vincent Lefevre writes: > > >> Is there a way to tell automake to omit it in DEFAULT_INCLUDES? > > > > nostdinc? > > > > 8.7 Variables used when building a program > > =

Re: Funny clang behaviour

On 2020-02-18 12:47:31 +0100, Niels Möller wrote: > Marc Glisse writes: > > > but in any case it seems like a good idea to avoid having a > > file with the same name as a standard header in a directory with a -I > > pointing to it. > > I wonder why we have an -I flag pointing to tests/mpz. We

Re: Small limb-size in mini-gmp?

On 2019-11-17 01:00:14 +0100, Torbjorn Granlund wrote: > We cannot use uint8_t as it is not a builtin type, as you know. I don't understand why you need a builtin type. It should work by conditionally including . Alternatively, you can predefine some types, e.g.: typedef unsigned char

Re: Small limb-size in mini-gmp?

On 2019-11-17 00:41:17 +0100, Torbjorn Granlund wrote: > "Marco Bodrato" writes: > > Committed. > > The needed space causes problems as this needs to go through several > scripts and evaluations. I am not sure how to get it working, actually. > > I think the original proposal to have the

Re: Small limb-size in mini-gmp?

On 2019-11-13 22:20:18 +0100, Niels Möller wrote: > t...@gmplib.org (Torbjörn Granlund) writes: > > > 2. follow Marco's proposal allowing "char", "short", "int", "long", and > > perhaps the spacey "long long" as overriding types, or > > I guess that's good enough for now. But is it that

Re: Small limb-size in mini-gmp?

On 2019-11-13 17:41:47 +0100, Marco Bodrato wrote: > I did hope that "unsigned" were just a modifier... > > But it seems that a line like the following is not allowed > > typedef unsigned uint128_t mp_limb_t > > I do not understand why... If it were a modifier, then I suppose that "signed"

Re: Small limb-size in mini-gmp?

On 2019-11-12 22:22:00 +0100, Marco Bodrato wrote: > Is something like the following too tricky? > > #ifndef MINI_GMP_LIMB_TYPE > #define MINI_GMP_LIMB_TYPE long > #endif > > typedef unsigned MINI_GMP_LIMB_TYPE mp_limb_t > > As only unsigned types are supported... Unsigned types do not

Re: [MPFR] New paper on triple-word arithmetic

On 2019-10-29 11:33:58 -0600, Nelson H. F. Beebe wrote: > I draw your attention to this new paper: > > N. Fabiano and J. Muller and J. Picot > Algorithms for Triple-Word Arithmetic > IEEE Transactions on Computers 68(11) 1573--1583 November 2019 >

Re: New n log n algorithm for high-precision multiplication

On 2019-04-15 10:22:02 +0200, Niels Möller wrote: > No, current GMP FFT multiplication is based on Schönhage-Strassen. > > There's also unfinished work on small-prime FFT, motivated mainly to get > better cache locality (for huge numbers, field elements in > Schönhage-Strassen get so large that

Re: Progresses for the next release? [Was: New code for primality testing]

On 2019-01-18 13:57:27 +0100, Torbjorn Granlund wrote: > We need to check that up-to-date tools work as expected. That's > straightforward except for texinfo, which in the past has caused > problems in particular for the pdf output. FYI, we had problems in MPFR due to the use of @var in

Re: mini-gmp

On 2018-12-21 01:43:12 +0100, Marco Bodrato wrote: > We know, we never claimed that mini-gmp was supporting different limb sizes. > The suggestion was "by Paul" :-) In https://gmplib.org/list-archives/gmp-devel/2018-December/005117.html you said: A attach a possible implementation of mini-gmp

Re: mini-gmp

On 2018-12-15 20:18:44 +0100, Niels Möller wrote: > Vincent Lefevre writes: > > > Yes, this is expected by MPFR. But since mini-gmp.c includes > > mini-gmp.h, this prevents one from redefining GMP_LIMB_BITS > > in mini-gmp.h, except by exactly the same content, whic

Re: mini-gmp

On 2018-12-15 09:48:41 +0100, Niels Möller wrote: > paul zimmermann writes: > > > would it be possible to move the following from mini-gmp.c to mini-gmp.h? > > > > #define GMP_LIMB_BITS (sizeof(mp_limb_t) * CHAR_BIT) > > > > It would expose GMP_LIMB_BITS to applications using mini-gmp, > >

Re: Micro-GMP

On 2018-12-11 09:21:39 +0100, Niels Möller wrote: > "Marco Bodrato" writes: > > > Supporting very small sizes, and odd sizes might not be easy. And > > currently Paul reported failures for 32-bit limbs on 64-bit machines... > > asl.h is more interesting for GMP than for mini-. > > And if we can

Re: Micro-GMP

On 2018-12-11 03:55:53 +0100, Marco Bodrato wrote: > Il Lun, 10 Dicembre 2018 10:07 pm, Niels Möller ha scritto: > > And I think we should always require that arithmetic on mp_limb_t is mod > > (GMP_LIMB_MAX + 1), so that & GMP_LIMB_MAX usually is redundant (with > > Do you mean I should have

Re: Micro-GMP

On 2018-12-10 13:51:05 +0100, Torbjorn Granlund wrote: > All this assuming no padding bits (I doubt they are supported), > which would make things even more complex. > > We sort of support the nails feature, which might be what you mean > by padding. It is poorly maintained, and never left

Re: Micro-GMP

On 2018-12-10 10:46:26 +0100, paul zimmermann wrote: >Dear Marco, > > > mpz_cmpabs_ui (const mpz_t u, unsigned long v) > > { > > int ulongsize = GMP_ULONG_BITS / GMP_LIMB_BITS; > > mp_limb_t ulongrem = 0; > > mp_size_t un = GMP_ABS (u->_mp_size); > > > > if (GMP_ULONG_BITS %

Re: mpz_get_si: possible undefined behaviour? [Was: Micro-GMP]

On 2018-12-04 07:39:52 +0100, Torbjorn Granlund wrote: > Marco Bodrato writes: > > But, what about the LONG_MIN == -LONG_MAX case? > The result is undefined, isn't it? > > Does anybody (apart from Vincent) have access to such a machine? > :-) I don't have access to such a machine :) but

Re: mpz_get_si: possible undefined behaviour? [Was: Micro-GMP]

On 2018-12-04 13:45:10 +0100, Torbjorn Granlund wrote: > Pedro Gimeno writes: > > An assertion of LONG_MIN < -LONG_MAX should make the code safe in that case. > > Does The Standard even guarantee thet there are about as many negative > and positive number? > > I am really worried that GMP

Re: mpz_get_si: possible undefined behaviour? [Was: Micro-GMP]

On 2018-12-03 23:47:00 +0100, Marco Bodrato wrote: > If LONG_MIN == -LONG_MAX-1, this step is correct. > But, what about the LONG_MIN == -LONG_MAX case? > The result is undefined, isn't it? Yes. > Which value we should actually return when the given mpz does not > fit in the target type is not

Re: Micro-GMP

On 2018-12-03 15:06:02 +0100, paul zimmermann wrote: > indeed, in several places I opted for simplicity, since speed was not > (at first) a goal. But when running "make check" of MPFR with micro-gmp-8, > I now realize speed is also important! Yes, in particular if we want to do exhaustive tests

Re: Micro-GMP

On 2018-12-03 13:57:32 +0100, paul zimmermann wrote: > > First public GMP releaae wasn't 1.3.2 (sic) in 1993 but 1.1 in 1991. > > my source was ftp://ftp.gnu.org/gnu/gmp/, where the first version is 1.3.2. Isn't ftp obsolete? Look at https://gmplib.org/download/gmp/archive/ instead.

Re: Micro-GMP

On 2018-12-03 13:04:11 +0100, Torbjorn Granlund wrote: > > What is the purpose of GMP_NEG_CAST > > > > #define GMP_NEG_CAST(T,x) (-((T)((x) + 1) - 1)) > > > > instead of just a cast followed by a negation? i.e. > > > > mpz_set_ui (r, - (unsigned long int) x); > > This is confusing.

Re: Micro-GMP

On 2018-11-30 15:57:24 +0100, Marco Bodrato wrote: > By the way, the code Paul wrote and I propose to simplify is the following. > > /* MPZ assignment and basic conversions. */ > /* function changed by PZ */ > void > mpz_set_si (mpz_t r, signed long int x) > { > if (x >= 0) > mpz_set_ui (r,

Re: mini-gmp test suite could be improved

On 2018-09-05 17:43:29 +0200, Vincent Lefevre wrote: > On 2018-09-05 16:00:18 +0200, Torbjorn Granlund wrote: > > Perhaps this can be automated and given a new, trendy name now that > > fuzzing has been on everybody's mind for so long? :-) > > An interesting place is

Re: mini-gmp test suite could be improved

On 2018-09-05 16:00:18 +0200, Torbjorn Granlund wrote: > paul zimmermann writes: > > void > mpz_add_ui (mpz_t r, const mpz_t a, unsigned long b) > { > b = b % 0x; > if (a->_mp_size >= 0) > r->_mp_size = mpz_abs_add_ui (r, a, b); > else > r->_mp_size =

Re: _ptr and _srcptr types

On 2018-05-22 21:45:34 +0200, Marco Bodrato wrote: > Ciao Emmanuel, > > Il Lun, 14 Maggio 2018 10:00 am, Emmanuel Thomé ha scritto: > > May I suggest one or several of the following things be done ? > > - document the mpz_srcptr type somewhere, so that the documentation is > >self-contained.

Re: _ptr and _srcptr types

On 2018-05-22 08:18:18 +0200, Vincent Lefevre wrote: > No, with variadic functions, a null pointer of some type is provided > as an argument, and then the value is re-read as another pointer type > (this is actually a simplification, because depending on the calling > conven

Re: _ptr and _srcptr types

On 2018-05-22 04:46:50 +0200, Pedro Gimeno wrote: > The C11 standard also says: > > P.47: > > 1. A pointer to void may be converted to or from a pointer to any incomplete > or object type. A pointer to any incomplete or object type may be converted > to a pointer to void and back again; the

Re: _ptr and _srcptr types

On 2018-05-20 22:07:36 +0200, Niels Möller wrote: > Vincent Lefevre <vinc...@vinc17.net> writes: > > > No, pointers to different types may have different representations, > > and in particular, different sizes. > > Hmm. I was aware that *function* pointers may

Re: _ptr and _srcptr types

On 2018-05-19 23:27:30 +0200, Niels Möller wrote: > Vincent Lefevre <vinc...@vinc17.net> writes: > > > I've just noticed that GMP provides mpz_inits, so that mpz_ptr is > > necessary: Since type checking cannot be done with variadic functions, > > one must provide

Re: _ptr and _srcptr types

I've just noticed that GMP provides mpz_inits, so that mpz_ptr is necessary: Since type checking cannot be done with variadic functions, one must provide types compatible with mpz_ptr, or the behavior is undefined. This is not an issue for mpz_t variables, but the last argument needs to be

Re: _ptr and _srcptr types

On 2018-05-16 14:04:02 +0200, Niels Möller wrote: > It shouldn't be so difficult for users familiar with the fine points of > arrays and pointers in C. mpz_t is a typedef for a size 1 array > containing the internal struct, and mpz_ptr is a pointer to the same > struct, i.e., the type that an

Re: _ptr and _srcptr types

Hi, On 2018-05-14 10:00:46 +0200, Emmanuel Thome wrote: > The mpz_ptr, mpz_srcptr types, and their many friends, are exposed in > gmp.h, but never seen in the documentation. (unless I'm mistaken.) > > Well, almost: > > ~/gmp $ grep 'mp[a-z]*_[a-z]*ptr' doc/gmp.texi > @deftypefun mpz_srcptr

Re: mini-gmp/README

On 2018-05-04 23:20:57 +0200, Marco Bodrato wrote: > Should we add to the "as specified in the GMP manual, with a few > exceptions:" section also this line? > > When mpz_get_str allocates the string, it can be longer than needed. If you say that, this means that the string is longer than

Re: Comparison of multiple-precision floating-point software

On 2018-04-25 11:30:28 +0200, Torbjorn Granlund wrote: > paul zimmermann writes: > > Now MPF is faster than MPFR for all 100d operations, for 1000d and 1d > div. You have done a great work in GMP 6! > > The differences there are marginal. Moreover, the new

Re: mpn_mul is embarrassingly slow

On 2018-04-24 14:11:34 +0200, paul zimmermann wrote: >Dear Torbjörn, > > > What do you think about this stopgap change? > > I would entirely drop all the squaring-related stuff from mpn_mul: > the user/developer should call mpn_sqr instead (see my previous mail). It is not clear that

Re: MPN_FILL vs MPN_ZERO

On 2018-04-24 12:46:27 +0200, paul zimmermann wrote: > I understand MPN_ZERO(p,n) is implemented as "if (n) MPN_FILL(p, n, 0)". > > Then in case MPN_FILL is implemented using memset, since memset also checks > for the case n=0, MPN_ZERO(p,n) will perform two tests for n > 0. Why not > directly

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: mpn_mul is embarrassingly slow

On 2018-04-20 04:14:15 +0200, Fredrik Johansson wrote: > For operands with 1-4 limbs, that is; on my machine, mpn_mul takes up to > twice as long as mpn_mul_basecase, and inline assembly for 1x1, 2x1 or 2x2 > multiplication is even faster. The problem is that there are three function > calls

Re: How large are arbitrarily large integers? (Was Re: Bitfield subtlety)

On 2018-03-29 11:27:24 +0200, Niels Möller wrote: > Richard Biener writes: > > > I would be surprised if that wouldn't work everywhere - any reason > > you have doubts? To clarify, allocation would work like > > > > void *ptr = malloc (... + sizeof (size_t)); > > ->_mp_d =

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

On 2018-03-16 22:22:39 +0100, Marc Glisse wrote: > On Fri, 16 Mar 2018, Marco Bodrato wrote: > > > float.h was defined by C99, right? > > I am pretty sure it was already in C89. Yes, but was DBL_MANT_DIG necessarily an integer constant expression (in case this is needed) at that time? --

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

On 2018-03-13 17:29:48 +0100, Marc Glisse wrote: > +1 to that. For mini-gmp, maybe put all the functions using 'double' behind > some macro or in a separate file so it is easy for a user to remove them, > and document that they are only supported with a standard float.h header. Or > just assume

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

On 2018-03-13 15:34:26 +0100, Torbjorn Granlund wrote: > ni...@lysator.liu.se (Niels Möller) writes: > If we can make this thread safe with C11, I think it's fine to document > that mini-gmp requires C11 for thread safety. (I'd still prefer the > simpler way of reying on float.h constants,

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

On 2018-03-13 15:12:27 +0100, Niels Möller wrote: > Does C11 provide any way to initialize a local static variable, like in > recent C++? I.e., not code running before main, but code running the > first time the function is entered, and guaranteed to run just once? I don't think so. 6.7.9p4 says

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

On 2018-03-13 13:55:27 +0100, Torbjorn Granlund wrote: > Vincent Lefevre <vinc...@vinc17.net> writes: > > On 2018-03-12 18:53:37 +0100, Marco Bodrato wrote: > > double > > mpz_get_d (const mpz_t u) > > { > > static int c =

Re: mini-gmp mpz_{get,set}_d not fully compatible with GMP

On 2018-03-12 18:53:37 +0100, Marco Bodrato wrote: > double > mpz_get_d (const mpz_t u) > { > static int c = 0; > static int __initialized = 0; > > if (__initialized != 1) { > c = gmp_tests_dbl_mant_bits (); > *((volatile int *) &__initialized) = 1; > } FYI, this is not

Re: Why set zero in zero.c rather than use xor_n

On 2018-02-05 22:46:58 +0100, Torbjorn Granlund wrote: > As suspected, memset adds quite some moverhead. This depends on what the compiler knows about the size. If GCC knows the size at compile time, it does not generate a call to memset: #include void foo (long *p) { memset (p, 0, 1); }

Re: Why set zero in zero.c rather than use xor_n

On 2018-02-05 21:48:47 +0100, Torbjorn Granlund wrote: > I suppose memset is not used as it might come with more overhead for > checking alignment. I haven't timed it, though. The compiler knows the alignment from the types. This is where the optimization should be. The GCC manual mentions a

Re: Why set zero in zero.c rather than use xor_n

On 2018-02-05 09:41:24 +, Win C wrote: > Hi! There are a lot of reports that using xor is faster than setting > a variable to zero. Therefore, I did a little test with the > following code: [...] Your test is wrong because after one iteration, the data will be in the cache. I mean that the

Re: mpn_sqrtrem{1,2} - rounding mode - erratum

On 2017-03-26 00:54:50 +0100, Adrien Prost-Boucle wrote: > > I tested with a function that repeatedly sets all rounding modes. > > The result is: 995413 calls to fesetround() per second on my laptop > > That's extremely slow given the speed of the sqrt function! > > Ooops there was a typo in my

Re: mpn_sqrtrem{1,2}

On 2017-03-16 14:45:58 +0100, Torbjörn Granlund wrote: > ni...@lysator.liu.se (Niels Möller) writes: > > I think the "long double" type means an 80-bit floating point format > which was implemented in the original 80387 floating point coprocessor. > And which isn't supported by the later

Re: Aw: Re: Help stabilising mini-gmp

On 2016-12-02 12:18:25 +0100, Wolf Lammen wrote: > Gesendet: Freitag, 02. Dezember 2016 um 01:30 Uhr > Von: "Vincent Lefevre" <vinc...@vinc17.net> > An: "Nelson H. F. Beebe" <be...@math.utah.edu> > Cc: gmp-devel@gmplib.org > Betreff: Re: Help stabi

Re: Help stabilising mini-gmp

On 2016-12-01 18:15:54 -0700, Nelson H. F. Beebe wrote: > Vincent clarifies about my response on about zero shift counts: > > >> ... > >> I'm not talking about a zero shift count, but a shift of the value 0 > >> with an arbitrary shift count, e.g. (uint64_t) 0 << 64. This is > >> undefined

Re: Help stabilising mini-gmp

On 2016-12-01 16:42:39 -0700, Nelson H. F. Beebe wrote: > Vincent Lefevre <vinc...@vinc17.net> asks in response to my lengthy > posting earlier today about where the behavior of bit-shift operations > allows undefined behavior in C and C++: > > >> ... > >> Is t

Re: Help stabilising mini-gmp

On 2016-11-25 18:39:28 +0100, Torbjörn Granlund wrote: > I assume "undefined" means that the computer will not explode, or even > cause any less dramatic security issues, or even terminate execution. Compilers use the fact that undefined behavior must not occur to do some optimizations, like

Re: Help stabilising mini-gmp

On 2016-12-01 08:57:12 -0700, Nelson H. F. Beebe wrote: > Notice that it does NOT prohibit left-shifting negative values: it > just says that behavior with negative SHIFT COUNTS is undefined. > > The reason for that is that low-level expressions in C have always > been intended, and assumed, to

Re: mpn_sqrtrem2

On 2016-07-20 15:23:24 +0200, paul zimmermann wrote: > the attached file contains a new version (mpn_sqrtrem2_new) of mpn_sqrtrem2 > for 64-bit computers. On my computer i5-4590 it runs in about 65 cycles > whereas the gmp-6.1.1 version runs in about 96 cycles. But the code is wrong on 32-bit

Re: Move -DNO_ASM to config.h?

On 2016-03-21 16:01:25 +0100, Marc Glisse wrote: > In https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69134 ( > https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00127.html ), users > specifically wanted to disable MPFR's copy ;-) That's because they're using a very old MPFR version (2.4.2). Normally,

Re: Move -DNO_ASM to config.h?

On 2016-03-20 12:14:49 +0100, Marc Glisse wrote: > I am guessing that, just like they want to use the exact same flags as GMP > to compile (__GMP_CFLAGS), they also want to mimic this part of the build > process. I don't know if their version of longlong.h is kept in sync with > GMP's, We try to

Re: Pull request: Raise SIGFPE instead of abort in __gmp_exception`

On 2016-01-07 21:45:44 +0100, Niels Möller wrote: > That said, it sounds reasonable to me to replace abort by raise(SIGFPE). > A configure check may be needed; I think both abort and raise are ANSI > C, but I suspect SIGFPE isn't. SIGFPE is at least in ISO C99. I don't know when it was

Re: Debian jessie does not include the gmp documentation

On 2015-10-27 19:51:29 +0100, Torbjörn Granlund wrote: > ni...@lysator.liu.se (Niels Möller) writes: > > I'm pretty sure that debian policy is to reject a GNU FDL manual if and > only if the manual in question includes any invariant sections. > > Apparently they are stricter than that,

Re: Debian jessie does not include the gmp documentation

On 2015-10-26 16:42:20 +0100, Joerg Arndt wrote: > The file /usr/share/doc/libgmp10/README.Debian > contains the mysterious sentences > > Sadly, due to licensing the GMP documentation is no longer shipped in > Debian. The package libgmp10-doc now contains only demo code. > > Any

Re: mpz_t caching

On 2015-09-04 12:28:21 +0200, Torbjörn Granlund wrote: > I don't think libraries should hoard memory to compensate poor malloc > implementations. If that became common practice, applications would use > more RAM without recourse. OK, forget my mail. After looking at the MPFR source, I can't see

Re: mpz_t caching

On 2015-09-07 12:36:51 +0200, Niels Möller wrote: > Vincent Lefevre <vinc...@vinc17.net> writes: > > > I suspect that the cause > > of the difference is that with mpz_t caching, the mpz_t's are > > preallocated with a size that is large enough to avoid internal

Re: mpz_t caching

On 2015-09-04 10:24:31 +0200, Niels Möller wrote: > Vincent Lefevre <vinc...@vinc17.net> writes: > > > In 2014, Patrick Pelissier (in Cc) implemented a mpz_t allocation > > cache for MPFR, redefining mpz_init and mpz_clear, in order to > > avoid some deallocations

mpz_t caching

Hi, In 2014, Patrick Pelissier (in Cc) implemented a mpz_t allocation cache for MPFR, redefining mpz_init and mpz_clear, in order to avoid some deallocations/allocations (via the indirect call to the allocation functions) when mpz_t's cleared and init'ed again a bit after. I've attached the patch

Re: fast inversion

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_size_t

Re: Additional memory handler features.

On 2015-01-04 11:41:02 -0500, Victor Shoup wrote: So let's ignore custom memory allocators for a minute, and just think about error handling. There are just a few viable approaches: 1) abort with error message (current approach) 2) return codes (the traditional C approach) 3) C++

Re: Additional memory handler features.

On 2015-01-04 23:17:16 +, David Harvey wrote: On 5 Jan 2015, at 10:08 am, Niels Möller ni...@lysator.liu.se wrote: Of course there are also some drawbacks. It makes life more complicated for applications, and the implementation of functions like mpn_mul_itch, which interact with pretty

Re: mpz_limbs interface

On 2014-02-06 11:54:04 +0100, Niels Möller wrote: Marc Glisse marc.gli...@inria.fr writes: + ASSERT (d != 0.5*d); /* Exclude infinities */ That excludes more than infinities, it might also exclude FLT_TRUE_MIN, no? I would have expected that FLT_TRUE_MIN * 0.5 == 0.0. And then it's

Re: mpz_limbs interface

On 2014-02-06 12:46:05 +0100, Niels Möller wrote: Vincent Lefevre vinc...@vinc17.net writes: You may need: ASSERT (d - d == 0); That should exclude both infinities and NaN:s, right? Yes. If you want to differentiate between NaN and infinities: d != d is true only for NaN. -- Vincent

Re: mini-gmp

On 2014-01-18 11:00:38 +0100, Zimmermann Paul wrote: 1) extract the GMP tarball in say /tmp/gmp-5.1.3 go into /tmp/gmp-5.1.3/mini-gmp add the following line in mini-gmp.c (say at line 43): char gmp_version[] = 5.1.3; Is there any reason to do that? As said a few days ago, mini-gmp

Re: mini-gmp

On 2014-01-15 23:54:27 +0100, Vincent Lefevre wrote: On 2014-01-15 23:23:28 +0100, Niels Möller wrote: Zimmermann Paul paul.zimmerm...@inria.fr writes: #define GMP_NUMB_BITS 64 It would make sense to have this (and GMP_LIMB_BITS) in mini-gmp.h. But the definition (which must

Re: Including limits.h in gmp-impl.h

On 2014-01-03 12:19:26 +0100, Marc Glisse wrote: On Fri, 3 Jan 2014, Torbjorn Granlund wrote: Vincent Lefevre vinc...@vinc17.net writes: Note that if you want to care of non-two's-complement implementations, you should write: Isn't the notion of 2's complement restricted to signed

Re: Including limits.h in gmp-impl.h

On 2013-12-25 13:28:20 +0100, Torbjorn Granlund wrote: IIRC, limits.h was unreliable for many years, and our workarounds allowed GMP to work on more systems. I've tried to find something about that on Google, but couldn't find anything. Any reference? -- Vincent Lefèvre vinc...@vinc17.net -

Re: A contribution to GMP

On 2013-10-24 10:01:32 +0200, Marc Glisse wrote: On Thu, 24 Oct 2013, Niels Möller wrote: I guess in theory, mpf could be slightly faster than mpfr since mpf doesn't make any effort to have precisely defined rounding. In that case I think it would be preferable to introduce a new don't care

Re: Does -0.5 fit an unsigned when truncated to an integer?

On 2013-03-19 11:59:17 +0100, Torbjorn Granlund wrote: Vincent Lefevre vinc...@vinc17.net writes: I haven't though a lot about this, but it is not clear that -1 + eps should be considered to fit an unsigned type. Why? We need to decide how to define the edge conditions. We

Re: Does -0.5 fit an unsigned when truncated to an integer?

On 2013-03-19 22:11:31 +0100, bodr...@mail.dm.unipi.it wrote: 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

Re: gmp-devel list

On 2013-03-06 09:53:05 +0100, Paul Zimmermann wrote: Niels, We need a forum for both posting patches, and discussing the same patches. To me, it seems easiest to have both on the same list. however maybe not all people on gmp-devel are interested by the detail of all patches and

Re: Public mpz_ptr and mpz_srcptr

On 2013-02-04 14:21:54 +0100, Vincent Lefevre wrote: On 2013-02-04 13:57:16 +0100, Torbjorn Granlund wrote: I chose to not provide mpz_ptr since I think it would be prone to errors. I expect code like this to be created: mpz_ptr foo (mpz_t a, mpz_t b) { mpz_t c; mpz_init (c

Re: Public mpz_ptr and mpz_srcptr

On 2013-02-04 14:26:38 +0100, Torbjorn Granlund wrote: Vincent Lefevre vinc...@vinc17.net writes: On 2013-02-04 13:57:16 +0100, Torbjorn Granlund wrote: I chose to not provide mpz_ptr since I think it would be prone to errors. I expect code like this to be created: mpz_ptr

Re: long long

On 2012-08-02 15:04:57 +0200, Joerg Arndt wrote: Is there any platform _apart_ from Windows64 where sizeof long != length of general purpose CPU registers ? 16-bit processors. I suspect that when there will be 128-bit processors, long will still be 64 bits, just like int is still 32 bits on

Re: long long

On 2012-07-31 09:51:00 +0200, Marc Glisse wrote: Some platforms provide types larger that intmax_t (intmax_t is part of the ABI, and they couldn't change it when they added a longer type, see for instance __int128 in gcc). GCC could have added an option to change the ABI, as it has done for

Re: GMP 5.0.5 build fails with tcc due to x86_64 asm (unknown register...)

On 2012-06-20 21:26:18 +0200, Torbjorn Granlund wrote: Let's first decide if it is worth spending time on. Just because somebody writes a compiler doesn't mean taat we need to feed GMP to it... Does anybody really need to use tcc for compiling GMP? Perhaps because of dependency. But I'm