On Monday 24 August 2009 23:54:39 Nils Bruin wrote:
> On Aug 24, 2:44 pm, Bill Hart <goodwillh...@googlemail.com> wrote:
> > void
> > mp_set_memory_functions (void *(*alloc_func) (size_t),
> > void *(*realloc_func) (void *, size_t, size_t),
> > void (*free_func) (void *, size_t))
> > {
> > if (alloc_func == 0)
> > alloc_func = __gmp_default_allocate;
> > if (realloc_func == 0)
> > realloc_func = __gmp_default_reallocate;
> > if (free_func == 0)
> > free_func = __gmp_default_free;
> >
> > __gmp_allocate_func = alloc_func;
> > __gmp_reallocate_func = realloc_func;
> > __gmp_free_func = free_func;
> >
> > }
> >
> > Not very extensive huh. I actually don't see a solution to this
> > problem that involves mpir. In fact I think this is a security issue
> > and I don't think this capability should even exist.
>
> I do not understand what you mean, partially because I don't
> understand what you mean by "this capability". If you think it's
> relevant, would you mind explaining a little more elaborately?
>
> In other news, I now see that my assumptions about ECLs usage of GMP
> do not hold at all. They are depending on GMP claiming memory for them
> almost everywhere.
> However, a bignum in C is immutable, so after its creation it does not
> change value anymore. So it might actually make sense to preallocate
> bignums as
> [mp_size, mp_d, <pointer to limb[0]>, mp_alloc, limb[0], limb
> [1], ... , limb[mp_alloc-1]]
> i.e., put the limbs straight after the mpz_t. That way, creating a
> bignum only takes one alloc, instead of two.
>
> We would have to ensure that enough limbs are allocated to upon
> creation. One way to do that would be to let GMP create the result in
> a temporary variable, copy over the limbs into the bignum and call
> gmp_free on the temporary variable (or keep the temp around for the
> next time). That would always incur an extra copy, but the current
> implementation in ECL does something along those lines (but not
> always).
>
> Does GMP have routines somewhere that predict how many limbs the sum,
> difference, product, exponential of an answer going to need? Naively,
> I would think:
>
> nlimbs(a+b) <= nlimbs(a)+nlimbs(b)+1
> nlimbs(a*b) <= nlimbs(a)*nlimbs(b)
nlimbs(a+b)<=max(nlimbs(a),nlimbs(b))+1
nlimbs(a*b)<=nlimbs(a)+nlimbs(b)
but this is for the answer only , it doesn't include any temp space needed to
perform the calculation eg we multiply by FFT and need approx 6x the space
above. The temp space is not just limbs but can include structures (eg
matrix'es for GCD calcs , prime tables for factorials,etc)
Perhaps if the sage process sets the ulimit stack high enough , then gmp can
use that (like it used to , back in the bad old days)
>
> etc.
>
> Is that correct? Or do certain optimizations/weird platforms mean that
> these naive bounds can be wrong?
>
> I think it should be possible to rewrite the bignums of ECL such that
> the only "mpz_t"s that GMP allocates/reallocates are "registers",
> i.e., temporary variables that do not need to be garbage collected,and
> if we can predict the sizes beforehand, we may even be able to gain
> some efficiency by eliminating some uses of "registers" in the current
> code.
> That might make the change a little more palatable to the ECL
> maintainers. It would also mean that the "embeddability" of ECL would
> increase a bit by not requiring that ECL administer the GMP's memory
> allocation.
>
>
>
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
