[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CPU and GC cost of bignums

From: Andy Wingo
Subject: Re: CPU and GC cost of bignums
Date: Thu, 06 Feb 2020 10:37:54 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

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
Generally we can use the low-level API to work on these
and if we need to use mpz_t, we can easily create an mpz_t that points
to these values.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]