Re: CPU and GC cost of bignums

[Andy Wingo]

Hi :)

Nice investigation!  Perhaps slot-allocation should track live variables
using something that's not bigints, but who knows.

On Wed 05 Feb 2020 17:29, Ludovic Courtès <address@hidden> writes:

>  /* The next three functions (custom_libgmp_*) are passed to
>     mp_set_memory_functions (in GMP) so that memory used by the digits
>     themselves is known to the garbage collector.  This is needed so
> @@ -237,19 +227,20 @@ finalize_bignum (void *ptr, void *data)
>  static void *
>  custom_gmp_malloc (size_t alloc_size)
>  {
> -  return scm_malloc (alloc_size);
> +  return scm_gc_malloc (alloc_size, "GMP");
>  }
>  
>  static void *
>  custom_gmp_realloc (void *old_ptr, size_t old_size, size_t new_size)
>  {
> -  return scm_realloc (old_ptr, new_size);
> +  return scm_gc_realloc (old_ptr, old_size, new_size, "GMP");
>  }
>  
>  static void
>  custom_gmp_free (void *ptr, size_t size)
>  {
> -  free (ptr);
> +  /* Do nothing: all memory allocated by GMP is under GC control and
> +     will be freed when needed.  */
>  }

I think this makes sense to me as a short-term fix.  The down-side is
that limbs can alias Scheme objects.

In the long-term I think we should be representing bignums as
pointerless objects whose first word is the tag and a word count,
followed by inline "limbs" (in the sense of
https://gmplib.org/manual/Nomenclature-and-Types.html#Nomenclature-and-Types).
Generally we can use the low-level API to work on these
(https://gmplib.org/manual/Low_002dlevel-Functions.html#Low_002dlevel-Functions),
and if we need to use mpz_t, we can easily create an mpz_t that points
to these values.

Cheers,

Andy