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)
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
-~----------~----~----~----~------~----~------~--~---
