On Tue, 8 Jan 2013, Torbjorn Granlund wrote: > ni...@lysator.liu.se (Niels M?ller) writes: > > Hmm. I guess one could go down to only 8 bits or so for the alloc field, > and for larger allocations, store the number of allocated limbs at the > head of the limb array (in the case limb size is not artificially small, > it could be just _mp_d[-1]). > > That's another idea. > > Do you think 48 bits (or 47 bits absolute value) for _mp_size will be > large enough for the foreseeable future (say, 10 years)? > > I think that will be sufficient for some hundred years, since any > super-linear algorithm applied to an operand of 2^53 bits (2^47 64-bit > limbs) would hardly ever terminate even with a multi-THz CPU. > > There are also other tweaks discussed for mpz_t, to allow initialization > without allocation. > > Yep, we should do that too. I cannot recall the details, but I assume > that this would not create an incompatibility?
Another idea is to embed limbs for small numbers into __mpz_struct itself (I was playing with that idea to reduce the number of allocations done by ISL used by GCC now). Sort of have a magic _mp_alloc number (zero?) that tells GMP that everything after _mp_alloc are the actual limbs. Thus have typedef struct { int _mp_alloc; int _mp_size; union { mp_libm_t *_mp_d; mp_libm_t embed_limbs[N]; }; } __mpz_struct; with suitable N (what's a suitable number of limbs to special-case, given that limb-size is target dependent? One limb would be easiest (just use the space of the _mp_d pointer), extra "half" limbs would be ugly I suppose. ISL has lots of arrays of __mpz_structs which seem to be often copied around and the actual numbers are usually small (would fit into 64bits). Doing this wouldn't create an incompatibility I think, but if you re-org things anyway maybe there is a better opportunity to layout things. Thanks, Richard. -- Richard Biener <rguent...@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel