MPS: optimized build

MPS: optimized build

[Gerd Möllmann]

I'm using an optimized build of scratch/igc today, in an attempt to
somehow distract myself from my sciatica. And I thought, why not write
someting about what I'm seeing. Who knows for what it's good.

This is of course macOS 14, Apple silicon.

So, anecdotal observations:

Survival time so far 1 hour, no crash. "Normal" usage for me, packages
I use and so on... YMMV.

I find build times surprising. 1:08 minutes with MPS (the non-debug
version), 1:18 without MPS. I would have expected the opposite, and with
a large difference. So much to intuition when it comes to performance,
but that only in passing.

Interactive use is, let me say, agreeable? :-)

I still see pauses sometimes but I would say these are not caused by
GC. I can see GC running BTW, with garbage-collection-messages set to
t and I've changed igc.c to write the messages to *Messages* to have a
better overview. So, synchronous process interaction, JSON parsing and
what else lead to some small pauses. No surprise.

In general, but I guess the wish is the father of the thought as we say
here, Emacs seems to be, hm, snappier? Consult, vertico, corfu, ...
completions, even typing text maybe?

Would be interesting to hear from others how they perceive it...

Re: MPS: optimized build

[Andrea Corallo]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> I'm using an optimized build of scratch/igc today, in an attempt to
> somehow distract myself from my sciatica. And I thought, why not write
> someting about what I'm seeing. Who knows for what it's good.
>
> This is of course macOS 14, Apple silicon.
>
> So, anecdotal observations:
>
> Survival time so far 1 hour, no crash. "Normal" usage for me, packages
> I use and so on... YMMV.
>
> I find build times surprising. 1:08 minutes with MPS (the non-debug
> version), 1:18 without MPS. I would have expected the opposite, and with
> a large difference. So much to intuition when it comes to performance,
> but that only in passing.
>
> Interactive use is, let me say, agreeable? :-)
>
> I still see pauses sometimes but I would say these are not caused by
> GC. I can see GC running BTW, with garbage-collection-messages set to
> t and I've changed igc.c to write the messages to *Messages* to have a
> better overview. So, synchronous process interaction, JSON parsing and
> what else lead to some small pauses. No surprise.
>
> In general, but I guess the wish is the father of the thought as we say
> here, Emacs seems to be, hm, snappier? Consult, vertico, corfu, ...
> completions, even typing text maybe?
>
> Would be interesting to hear from others how they perceive it...


Cool!

If you are there you might want to have a run with elisp-benchmarks [1].
IIRC one or two were GC bounded so we might see some difference 😃.

Thanks

  Andrea

[1] <https://elpa.gnu.org/packages/elisp-benchmarks.html>

Re: MPS: optimized build

[Gerd Möllmann]

Andrea Corallo <acorallo@gnu.org> writes:

> If you are there you might want to have a run with elisp-benchmarks [1].
> IIRC one or two were GC bounded so we might see some difference 😃.

I'd rather leave that to someone else.

I'm only interested in user experience, hard figures could only get in
the way :-).

Re: MPS: optimized build

[Andrea Corallo]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> If you are there you might want to have a run with elisp-benchmarks [1].
>> IIRC one or two were GC bounded so we might see some difference 😃.
>
> I'd rather leave that to someone else.
>
> I'm only interested in user experience, hard figures could only get in
> the way :-).

I agree with you, problem is user experience is often difficult to
quantify ;)

  Andrea

Re: MPS: optimized build

[Helmut Eller]

On Sun, May 05 2024, Andrea Corallo wrote:

> [1] <https://elpa.gnu.org/packages/elisp-benchmarks.html>

I ran those with:

  emacs -Q -batch
   -l ~/.emacs.d/elpa/elisp-benchmarks-1.14/elisp-benchmarks.el
   -eval '(elisp-benchmarks-run nil nil 1)' 2>&1 |tee /tmp/mps-result.txt

the results are below.

I had to disable the pidigits program because the MPS version ate all
memory and began to swap.  There's probably something wrong with
bignums.

For most programs the two versions are relatively close, except for
nbody where the old GC does much better.  The nbody program seems to
involve floating point arithmetic.  Maybe there's something wrong with
floats too.  Or maybe the extra header costs so much.

|                    |  MPS        || old GC
|--------------------------------------------------------------
| test               | tot avg (s) || gc avg (s) | tot avg (s) 
|--------------------+-------------+|------------+-------------
| bubble             |        6.59 ||       0.80 |        4.84 
| bubble-no-cons     |       11.99 ||       0.00 |       11.13 
| bytecomp           |        4.94 ||       0.75 |        4.59 
| dhrystone          |        9.05 ||       0.00 |        9.03 
| eieio              |        4.55 ||       0.00 |        3.78 
| fibn               |        2.77 ||       0.00 |        2.75 
| fibn-named-let     |        3.28 ||       0.00 |        3.30 
| fibn-rec           |        5.77 ||       0.00 |        6.04 
| fibn-tc            |        4.54 ||       0.00 |        4.49 
| flet               |        9.71 ||       0.00 |       10.27 
| inclist            |       14.45 ||       0.00 |       14.50 
| inclist-type-hints |       14.44 ||       0.00 |       14.50 
| listlen-tc         |        4.72 ||       0.00 |        4.76 
| map-closure        |        9.28 ||       0.00 |        9.19 
| nbody              |       12.32 ||       0.00 |        5.63 
| pack-unpack        |        0.98 ||       0.00 |        0.81 
| pack-unpack-old    |        2.85 ||       0.00 |        2.44 
| pcase              |       11.28 ||       0.00 |       11.18 
| scroll             |        1.54 ||       0.00 |        1.33 
| smie               |        3.30 ||       0.00 |        2.95 
|--------------------+-------------+|------------+-------------
| total              |      138.37 ||       1.55 |      127.50 

Re: MPS: optimized build

[Andrea Corallo]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Sun, May 05 2024, Andrea Corallo wrote:
>
>> [1] <https://elpa.gnu.org/packages/elisp-benchmarks.html>
>
> I ran those with:

Thanks!

>   emacs -Q -batch
>    -l ~/.emacs.d/elpa/elisp-benchmarks-1.14/elisp-benchmarks.el
>    -eval '(elisp-benchmarks-run nil nil 1)' 2>&1 |tee /tmp/mps-result.txt
>
> the results are below.
>
> I had to disable the pidigits program because the MPS version ate all
> memory and began to swap.  There's probably something wrong with
> bignums.

That's a pity, AFAIR pidigits was the one heavy on GC.

> For most programs the two versions are relatively close, except for
> nbody where the old GC does much better.  The nbody program seems to
> involve floating point arithmetic.  Maybe there's something wrong with
> floats too.  Or maybe the extra header costs so much.

Few others shows a noticeable performance slowdown, (assuming it's not
just noise of course).  There time to look into what's really going on
tho :)

Thanks

  Andrea

MPS: bignums (was: MPS: optimized build)

[Helmut Eller]

On Mon, May 06 2024, Helmut Eller wrote:

> I had to disable the pidigits program because the MPS version ate all
> memory and began to swap.  There's probably something wrong with
> bignums.

It seems that bignums aren't freed because that would need finalization.
But as long as Emacs is busy executing the benchmark program, it doesn't
process finalization messages.

We could create a separate finalization thread that processes these
messages.  For bignums this thread could call mpz_clear, which I suppose
is thread safe.  Things aren't so easy for the case where we need to
call a Lisp function.  We could create a timer that calls this function.

WDYT?

Re: MPS: bignums

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Mon, May 06 2024, Helmut Eller wrote:
>
>> I had to disable the pidigits program because the MPS version ate all
>> memory and began to swap.  There's probably something wrong with
>> bignums.
>
> It seems that bignums aren't freed because that would need finalization.
> But as long as Emacs is busy executing the benchmark program, it doesn't
> process finalization messages.
>
> We could create a separate finalization thread that processes these
> messages.  For bignums this thread could call mpz_clear, which I suppose
> is thread safe.  Things aren't so easy for the case where we need to
> call a Lisp function.  We could create a timer that calls this function.
>
> WDYT?

Could we perhaps use the fact that this works in the old GC somehow? I
mean, we know that clear_vector does that in the old GC (or so I think).
And that is called from garbage_collect often enough. What if we handled
MPS messages there, and not only when Emacs is idle?

Re: MPS: bignums (was: MPS: optimized build)

[Mattias Engdegård]

7 maj 2024 kl. 09.13 skrev Helmut Eller <eller.helmut@gmail.com>:
> 
> On Mon, May 06 2024, Helmut Eller wrote:
> 
>> I had to disable the pidigits program because the MPS version ate all
>> memory and began to swap.  There's probably something wrong with
>> bignums.
> 
> It seems that bignums aren't freed because that would need finalization.

Surely we must be able to allocate bignums in a single chunk? It's the ultimate leaf value, no references to anything else inside.

I understand that you want to do the least amount of work now, and that's fine. Just ignore bignum performance, at least for now; it rarely matters. (We could even drop GMP if that would help the memory management but it probably wouldn't.)

Re: MPS: bignums

[Helmut Eller]

On Tue, May 07 2024, Mattias Engdegård wrote:

> Surely we must be able to allocate bignums in a single chunk? It's the
> ultimate leaf value, no references to anything else inside.

It's not so easy.  A mpz_t is a resizable vector of "limbs".  The memory
for the mpz_t struct are managed by MPS but the memory for the limbs
isn't.  The function mp_set_memory_functions could perhaps be used to
allocate limbs in an MPS managed pool; but these functions include a
realloc variant which is not directly supported by MPS.  We would also
have to trace the reference to the limbs.

The reason why mpz_t in GMP is a mutable type is probably because they
need computations of the kind a := a + b a lot when doing crypto stuff
and in this case memory can be reused efficiently.

> I understand that you want to do the least amount of work now, and
> that's fine. Just ignore bignum performance, at least for now; it
> rarely matters. (We could even drop GMP if that would help the memory
> management but it probably wouldn't.)

I think we need to get finalization not just for bignums but also for
hash tables.

Re: MPS: bignums

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> I think we need to get finalization not just for bignums but also for
> hash tables.

Yeah, you malloc, you finalize :-).

The keys and values will have to move to MPS at some point. That's
needed for weak tables. One could also allocate next and index from MPS.
Some day. I don't feel like hash-tableing ATM ;-).

Re: MPS: bignums

[Mattias Engdegård]

7 maj 2024 kl. 11.06 skrev Helmut Eller <eller.helmut@gmail.com>:

> It's not so easy.  A mpz_t is a resizable vector of "limbs".  The memory
> for the mpz_t struct are managed by MPS but the memory for the limbs
> isn't.  The function mp_set_memory_functions could perhaps be used to
> allocate limbs in an MPS managed pool; but these functions include a
> realloc variant which is not directly supported by MPS.  We would also
> have to trace the reference to the limbs.

We could use the mpn interface directly but it's less convenient and mpz takes care of boring work, as well as some useful logic so it's probably not worth it.

> The reason why mpz_t in GMP is a mutable type is probably because they
> need computations of the kind a := a + b a lot when doing crypto stuff
> and in this case memory can be reused efficiently.

Yes, but our bignums aren't mutable. I think it would probably end up cheaper to use scratch mpz for the computation, create a single MPS allocation for the bignum, and memcpy the data to it. (Especially since bignums are small.)

> I think we need to get finalization not just for bignums but also for
> hash tables.

Yes, but that's actually necessary: they are mutable and can grow. For bignums, finalisation is accidental.

Re: MPS: bignums

[Gerd Möllmann]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 7 maj 2024 kl. 11.06 skrev Helmut Eller <eller.helmut@gmail.com>:
>
>> It's not so easy.  A mpz_t is a resizable vector of "limbs".  The memory
>> for the mpz_t struct are managed by MPS but the memory for the limbs
>> isn't.  The function mp_set_memory_functions could perhaps be used to
>> allocate limbs in an MPS managed pool; but these functions include a
>> realloc variant which is not directly supported by MPS.  We would also
>> have to trace the reference to the limbs.
>
> We could use the mpn interface directly but it's less convenient and mpz takes care of boring work, as well as some useful logic so it's probably not worth it.
>
>> The reason why mpz_t in GMP is a mutable type is probably because they
>> need computations of the kind a := a + b a lot when doing crypto stuff
>> and in this case memory can be reused efficiently.
>
> Yes, but our bignums aren't mutable. I think it would probably end up
> cheaper to use scratch mpz for the computation, create a single MPS
> allocation for the bignum, and memcpy the data to it. (Especially
> since bignums are small.)
>
>> I think we need to get finalization not just for bignums but also for
>> hash tables.
>
> Yes, but that's actually necessary: they are mutable and can grow. For bignums, finalisation is accidental.

For the uninitiated: This is not directly related to MPS. Bignums are
the same as before with igc.

Re: MPS: bignums

[Helmut Eller]

On Tue, May 07 2024, Mattias Engdegård wrote:

>> The reason why mpz_t in GMP is a mutable type is probably because they
>> need computations of the kind a := a + b a lot when doing crypto stuff
>> and in this case memory can be reused efficiently.
>
> Yes, but our bignums aren't mutable. I think it would probably end up
> cheaper to use scratch mpz for the computation, create a single MPS
> allocation for the bignum, and memcpy the data to it. (Especially
> since bignums are small.)

I tried to do this but the expression *xbignum_val is used all over the
place.  And I didn't want to add two dozens #ifdefs for this; so I gave
up.

Re: MPS: bignums

[Mattias Engdegård]

7 maj 2024 kl. 18.33 skrev Helmut Eller <eller.helmut@gmail.com>:

> I tried to do this but the expression *xbignum_val is used all over the
> place.  And I didn't want to add two dozens #ifdefs for this; so I gave
> up.

You did right, no reason to waste your time on this now.

Re: MPS: bignums

[Helmut Eller]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

On Tue, May 07 2024, Helmut Eller wrote:

> I tried to do this but the expression *xbignum_val is used all over the
> place.  And I didn't want to add two dozens #ifdefs for this; so I gave
> up.

I figured out a macro so that the ifdefs aren't needed.  Then I tried
it.  The pidigits benchmark runs to completion but the performance hit
is even worse than for nbody:

           |  MPS       ||           old GC 
------------------------------------------------------
| test     |tot avg (s) || gc avg (s) | tot avg (s) |
|----------+------------++------------+-------------+
| pidigits |      55.57 ||       2.44 |       11.82 |

Ahem. The patches are attached but its doubtful that they are an improvement.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Zero-rank-bignums.patch --]
[-- Type: text/x-diff, Size: 11560 bytes --]

From 6b96aa9b8aff4d934a22e4f03594d3573cacf1ed Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut@gmail.com>
Date: Wed, 8 May 2024 10:17:40 +0200
Subject: [PATCH 1/3] Zero-rank bignums

Allocate bignums in AMCZ.

* src/bignum.h (struct Lisp_Bignum): Use a layout without
pointers.
(bignum_val, xbignum_val, _bignum_val, _xbignum_val)
(bignum_integer): These now need to convert the internal
representation to mpz_t.
* src/bignum.c (make_bignum_from_mpz): New.
(make_bignum_bits, make_bignum_str): Use it.
* src/igc.h (struct igc_bignum_header): Describe the header for
bignums with bitfields for use in bignum.h.
(igc_make_bignum): New.
* src/igc.c (igc_make_bignum): Implement it.
(igc_obj_type, obj_type_names): Add IGC_OBJ_BIGNUM.
(thread_ap): Allocate bignums in leaf_ap.
(dflt_scanx): Bignums no longer need scanning.
(finalize_bignum, finalize_vector, finalize): Neither finalization.
* src/alloc.c (make_pure_bignum): Not needed; at least on 64bit machines.
* src/pdumper.c (dump_bignum, dump_cold_bignum)
(dump_do_dump_relocation): Not need so far.
---
 src/alloc.c   |  8 ++++++++
 src/bignum.c  | 36 +++++++++++++++++++++++++++++++++-
 src/bignum.h  | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++
 src/igc.c     | 38 ++++++++++++++++++++++++------------
 src/igc.h     | 20 +++++++++++++++++++
 src/pdumper.c | 20 +++++++++++++++++++
 6 files changed, 163 insertions(+), 13 deletions(-)

diff --git a/src/alloc.c b/src/alloc.c
index 3a9186285c8..9dd620dc000 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -6073,6 +6073,13 @@ make_pure_float (double num)
   return new;
 }
 
+#ifdef HAVE_MPS
+static Lisp_Object
+make_pure_bignum (Lisp_Object value)
+{
+  emacs_abort ();
+}
+#else
 /* Value is a bignum object with value VALUE allocated from pure
    space.  */
 
@@ -6101,6 +6108,7 @@ make_pure_bignum (Lisp_Object value)
 
   return make_lisp_ptr (b, Lisp_Vectorlike);
 }
+#endif
 
 /* Return a vector with room for LEN Lisp_Objects allocated from
    pure space.  */
diff --git a/src/bignum.c b/src/bignum.c
index 1fe195d78ea..66e0431f681 100644
--- a/src/bignum.c
+++ b/src/bignum.c
@@ -86,6 +86,28 @@ double_to_integer (double d)
   return make_integer_mpz ();
 }
 
+#ifdef HAVE_MPS
+static Lisp_Object
+make_bignum_from_mpz (const mpz_t z)
+{
+  size_t nlimbs = mpz_size (z);
+  const mp_limb_t *limbs = mpz_limbs_read (z);
+  bool negative = mpz_sgn (z) < 0;
+  struct Lisp_Bignum *i = igc_make_bignum (nlimbs, limbs, negative);
+  return make_lisp_ptr (i, Lisp_Vectorlike);
+}
+
+static Lisp_Object
+make_bignum_bits (size_t bits)
+{
+  if (bits > integer_width)
+    {
+      overflow_error ();
+    }
+  Lisp_Object i = make_bignum_from_mpz (mpz[0]);
+  return i;
+}
+#else
 /* Return a Lisp integer equal to mpz[0], which has BITS bits and which
    must not be in fixnum range.  Set mpz[0] to a junk value.  */
 static Lisp_Object
@@ -105,6 +127,7 @@ make_bignum_bits (size_t bits)
   mpz_swap (b->value, mpz[0]);
   return make_lisp_ptr (b, Lisp_Vectorlike);
 }
+#endif
 
 /* Return a Lisp integer equal to mpz[0], which must not be in fixnum range.
    Set mpz[0] to a junk value.  */
@@ -429,7 +452,17 @@ bignum_to_string (Lisp_Object num, int base)
    NUM must consist of an optional '-', a nonempty sequence
    of base-BASE digits, and a terminating null byte, and
    the represented number must not be in fixnum range.  */
-
+#ifdef HAVE_MPS
+Lisp_Object
+make_bignum_str (char const *num, int base)
+{
+  mpz_t tmp;
+  mpz_init (tmp);
+  int check = mpz_set_str (tmp, num, base);
+  eassert (check == 0);
+  return make_bignum_from_mpz (tmp);
+}
+#else
 Lisp_Object
 make_bignum_str (char const *num, int base)
 {
@@ -440,6 +473,7 @@ make_bignum_str (char const *num, int base)
   eassert (check == 0);
   return make_lisp_ptr (b, Lisp_Vectorlike);
 }
+#endif
 
 /* Check that X is a Lisp integer in the range LO..HI.
    Return X's value as an intmax_t.  */
diff --git a/src/bignum.h b/src/bignum.h
index 2749f8370d0..33ee9460a73 100644
--- a/src/bignum.h
+++ b/src/bignum.h
@@ -24,17 +24,28 @@ #define BIGNUM_H
 
 #include <gmp.h>
 #include "lisp.h"
+#ifdef HAVE_MPS
+#include "igc.h"
+#endif
 
 /* Number of data bits in a limb.  */
 #ifndef GMP_NUMB_BITS
 enum { GMP_NUMB_BITS = TYPE_WIDTH (mp_limb_t) };
 #endif
 
+#ifdef HAVE_MPS
+struct Lisp_Bignum
+{
+  union vectorlike_header header;
+  mp_limb_t limbs[];
+} GCALIGNED_STRUCT;
+#else
 struct Lisp_Bignum
 {
   union vectorlike_header header;
   mpz_t value;
 } GCALIGNED_STRUCT;
+#endif
 
 extern mpz_t mpz[5];
 
@@ -82,6 +93,48 @@ mpz_set_uintmax (mpz_t result, uintmax_t v)
     mpz_set_uintmax_slow (result, v);
 }
 
+#ifdef HAVE_MPS
+
+/* Macro trickery to hide differences with non-MPS version. */
+#define bignum_val(i) _bignum_val (alloca (sizeof (mpz_t)), i)
+#define xbignum_val(i) _xbignum_val (alloca (sizeof (mpz_t)), i)
+
+INLINE mpz_t const *
+_bignum_val (mpz_t *tmp, struct Lisp_Bignum const *i)
+{
+  const struct igc_bignum_header h = { .u.word = i->header.size };
+  const mp_limb_t *limbs = i->limbs;
+  const __mpz_struct z = {
+    ._mp_alloc = h.u.bits.nlimbs,
+    ._mp_size = (h.u.bits.sign_bit == 0) ? h.u.bits.nlimbs : -h.u.bits.nlimbs,
+    ._mp_d = (mp_limb_t *)limbs,
+  };
+  *tmp[0] = z;
+  return tmp;
+}
+
+INLINE mpz_t const *
+_xbignum_val (mpz_t *tmp, Lisp_Object i)
+{
+  return _bignum_val (tmp, XBIGNUM (i));
+}
+
+INLINE mpz_t const *
+bignum_integer (mpz_t *tmp, Lisp_Object i)
+{
+  if (FIXNUMP (i))
+    {
+      mpz_set_intmax (*tmp, XFIXNUM (i));
+    }
+  else
+    {
+      mpz_set (*tmp, *xbignum_val (i));
+    }
+  /* The unnecessary cast pacifies a buggy GCC 4.8.5.  */
+  return (mpz_t const *)tmp;
+}
+
+#else
 /* Return a pointer to the mpz_t value represented by the bignum I.
    It is const because the value should not change.  */
 INLINE mpz_t const *
@@ -109,6 +162,7 @@ bignum_integer (mpz_t *tmp, Lisp_Object i)
     }
   return xbignum_val (i);
 }
+#endif
 
 /* Set RESULT to the value stored in the Lisp integer I.  If I is a
    big integer, copy it to RESULT.  RESULT must already be
diff --git a/src/igc.c b/src/igc.c
index 4b3352de8b9..15b91e32ffb 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -202,6 +202,7 @@ #define IGC_DEFINE_LIST(data)                                                  \
   IGC_OBJ_FACE,
   IGC_OBJ_FACE_CACHE,
   IGC_OBJ_FLOAT,
+  IGC_OBJ_BIGNUM,
   IGC_OBJ_BLV,
   IGC_OBJ_WEAK,
   IGC_OBJ_PTR_VEC,
@@ -214,8 +215,8 @@ #define IGC_DEFINE_LIST(data)                                                  \
   "IGC_OBJ_STRING",	 "IGC_OBJ_STRING_DATA", "IGC_OBJ_VECTOR",
   "IGC_OBJ_ITREE_TREE",	 "IGC_OBJ_ITREE_NODE",	"IGC_OBJ_IMAGE",
   "IGC_OBJ_IMAGE_CACHE", "IGC_OBJ_FACE",	"IGC_OBJ_FACE_CACHE",
-  "IGC_OBJ_FLOAT",	 "IGC_OBJ_BLV",		"IGC_OBJ_WEAK",
-  "IGC_OBJ_PTR_VEC,"
+  "IGC_OBJ_FLOAT",	 "IGC_OBJ_BIGNUM",	"IGC_OBJ_BLV",
+  "IGC_OBJ_WEAK",	 "IGC_OBJ_PTR_VEC",
 };
 
 igc_static_assert (ARRAYELTS (obj_type_names) == IGC_OBJ_LAST);
@@ -1265,6 +1266,7 @@ dflt_scanx (mps_ss_t ss, mps_addr_t base_start, mps_addr_t base_limit,
 
 	  case IGC_OBJ_STRING_DATA:
 	  case IGC_OBJ_FLOAT:
+	  case IGC_OBJ_BIGNUM:
 	  case IGC_OBJ_LAST:
 	    emacs_abort ();
 
@@ -2327,12 +2329,6 @@ finalize_obarray (struct Lisp_Obarray *o)
 }
 #endif
 
-static void
-finalize_bignum (struct Lisp_Bignum *n)
-{
-  mpz_clear (n->value);
-}
-
 static void
 finalize_font (struct font *font)
 {
@@ -2446,10 +2442,6 @@ finalize_vector (mps_addr_t v)
       finalize_hash_table (v);
       break;
 
-    case PVEC_BIGNUM:
-      finalize_bignum (v);
-      break;
-
     case PVEC_FONT:
       finalize_font (v);
       break;
@@ -2536,6 +2528,7 @@ finalize_vector (mps_addr_t v)
     case PVEC_MARKER:
     case PVEC_WEAK_REF:
     case PVEC_MODULE_GLOBAL_REFERENCE:
+    case PVEC_BIGNUM:
       igc_assert (!"finalization not implemented");
       break;
     }
@@ -2566,6 +2559,7 @@ finalize (struct igc *gc, mps_addr_t base)
     case IGC_OBJ_FACE:
     case IGC_OBJ_FACE_CACHE:
     case IGC_OBJ_FLOAT:
+    case IGC_OBJ_BIGNUM:
     case IGC_OBJ_WEAK:
     case IGC_OBJ_BLV:
     case IGC_OBJ_PTR_VEC:
@@ -2722,6 +2716,7 @@ thread_ap (enum igc_obj_type type)
 
     case IGC_OBJ_STRING_DATA:
     case IGC_OBJ_FLOAT:
+    case IGC_OBJ_BIGNUM:
       return t->d.leaf_ap;
     }
   emacs_abort ();
@@ -2853,6 +2848,25 @@ igc_make_float (double val)
   return make_lisp_ptr (f, Lisp_Float);
 }
 
+struct Lisp_Bignum *
+igc_make_bignum (size_t nlimbs, const size_t *limbs, bool negative)
+{
+  igc_assert (nlimbs
+	      < (1 << (PSEUDOVECTOR_REST_BITS + PSEUDOVECTOR_SIZE_BITS - 1)));
+  struct Lisp_Bignum *i = alloc (sizeof *i + sizeof (size_t) * nlimbs,
+				 IGC_OBJ_BIGNUM, PVEC_FREE);
+  struct igc_bignum_header h = {
+    .u.bits.nlimbs = nlimbs,
+    .u.bits.sign_bit = negative,
+    .u.bits.type = PVEC_BIGNUM,
+    .u.bits.pvec_bit = 1,
+    .u.bits.mark_bit = 0,
+  };
+  i->header.size = h.u.word;
+  memcpy (i->limbs, limbs, sizeof (size_t) * nlimbs);
+  return i;
+}
+
 static unsigned char *
 alloc_string_data (size_t nbytes, bool clear)
 {
diff --git a/src/igc.h b/src/igc.h
index d5ac3a81f92..d6c9fd486d9 100644
--- a/src/igc.h
+++ b/src/igc.h
@@ -99,6 +99,26 @@ #define EMACS_IGC_H
 struct Lisp_Weak_Ref;
 Lisp_Object igc_weak_ref_deref (struct Lisp_Weak_Ref *);
 
+struct igc_bignum_header
+{
+  union
+  {
+    struct
+    {
+      size_t nlimbs : PSEUDOVECTOR_SIZE_BITS + PSEUDOVECTOR_REST_BITS - 1;
+      size_t sign_bit : 1;
+      size_t type : 6;
+      size_t unused : (BITS_PER_BITS_WORD - 32);
+      size_t pvec_bit : 1;
+      size_t mark_bit : 1;
+    } bits;
+    size_t word;
+  } u;
+};
+
+struct Lisp_Bignum *igc_make_bignum (size_t nlimbs, size_t const *limbs,
+				     bool negative);
+
 INLINE bool
 WEAK_REF_P (Lisp_Object x)
 {
diff --git a/src/pdumper.c b/src/pdumper.c
index 485e5b2232a..6fa0392b3e6 100644
--- a/src/pdumper.c
+++ b/src/pdumper.c
@@ -2232,6 +2232,13 @@ dump_finalizer (struct dump_context *ctx,
   dump_off nlimbs;
 };
 
+#ifdef HAVE_MPS
+static dump_off
+dump_bignum (struct dump_context *ctx, Lisp_Object object)
+{
+  emacs_abort ();
+}
+#else
 static dump_off
 dump_bignum (struct dump_context *ctx, Lisp_Object object)
 {
@@ -2269,6 +2276,7 @@ dump_bignum (struct dump_context *ctx, Lisp_Object object)
 
   return bignum_offset;
 }
+#endif
 
 static dump_off
 dump_float (struct dump_context *ctx, const struct Lisp_Float *lfloat)
@@ -3539,6 +3547,13 @@ dump_cold_buffer (struct dump_context *ctx, Lisp_Object data)
   dump_write (ctx, b->own_text.beg, ptrdiff_t_to_dump_off (nbytes));
 }
 
+#ifdef HAVE_MPS
+static void
+dump_cold_bignum (struct dump_context *ctx, Lisp_Object object)
+{
+  emacs_abort ();
+}
+#else
 static void
 dump_cold_bignum (struct dump_context *ctx, Lisp_Object object)
 {
@@ -3557,6 +3572,7 @@ dump_cold_bignum (struct dump_context *ctx, Lisp_Object object)
       dump_write (ctx, &limb, sizeof (limb));
     }
 }
+#endif
 
 #ifdef HAVE_NATIVE_COMP
 static void
@@ -5563,6 +5579,9 @@ dump_do_dump_relocation (const uintptr_t dump_base,
       }
 #endif
     case RELOC_BIGNUM:
+#ifdef HAVE_MPS
+      emacs_abort ();
+#else
       {
         struct Lisp_Bignum *bignum = dump_ptr (dump_base, reloc_offset);
         struct bignum_reload_info reload_info;
@@ -5573,6 +5592,7 @@ dump_do_dump_relocation (const uintptr_t dump_base,
         mpz_roinit_n (bignum->value, limbs, reload_info.nlimbs);
         break;
       }
+#endif
     default: /* Lisp_Object in the dump; precise type in reloc.type */
       {
         Lisp_Object lv = dump_make_lv_from_reloc (dump_base, reloc);
-- 
2.39.2


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Fix-bignums-32-bit-machines.patch --]
[-- Type: text/x-diff, Size: 2754 bytes --]

From 1ff0460b0d47345d8ab4c8ff547904f91f36978b Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut@gmail.com>
Date: Wed, 8 May 2024 11:36:05 +0200
Subject: [PATCH 2/3] Fix bignums 32-bit machines

* src/igc.h (struct igc_bignum_header): Can't define zero width
bitfields.
* src/igc.c (fix_terminal, igc_make_image_cache): Allow
compilation if not HAVE_WINDOW_SYSTEM.
* src/pdumper.c (dump_bignum): Implement it.
---
 src/igc.c     |  4 ++++
 src/igc.h     |  2 ++
 src/pdumper.c | 12 +++++++++++-
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/src/igc.c b/src/igc.c
index 15b91e32ffb..0168d6c7085 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -1648,7 +1648,9 @@ fix_terminal (mps_ss_t ss, struct terminal *t)
   {
     IGC_FIX_CALL_FN (ss, struct Lisp_Vector, t, fix_vectorlike);
     IGC_FIX12_RAW (ss, &t->next_terminal);
+#ifdef HAVE_WINDOW_SYSTEM
     IGC_FIX12_RAW (ss, &t->image_cache);
+#endif
     // These are malloc'd, so they can be accessed.
     IGC_FIX_CALL_FN (ss, struct coding_system, t->keyboard_coding, fix_coding);
     IGC_FIX_CALL_FN (ss, struct coding_system, t->terminal_coding, fix_coding);
@@ -3010,12 +3012,14 @@ igc_make_ptr_vec (size_t n)
   return alloc (n * sizeof (void *), IGC_OBJ_PTR_VEC, PVEC_FREE);
 }
 
+#ifdef HAVE_WINDOW_SYSTEM
 struct image_cache *
 igc_make_image_cache (void)
 {
   struct image_cache *c = alloc (sizeof *c, IGC_OBJ_IMAGE_CACHE, PVEC_FREE);
   return c;
 }
+#endif
 
 DEFUN ("igc-make-weak-ref", Figc_make_weak_ref, Sigc_make_weak_ref, 1, 1, 0,
        doc
diff --git a/src/igc.h b/src/igc.h
index d6c9fd486d9..85454cfd6f0 100644
--- a/src/igc.h
+++ b/src/igc.h
@@ -108,7 +108,9 @@ #define EMACS_IGC_H
       size_t nlimbs : PSEUDOVECTOR_SIZE_BITS + PSEUDOVECTOR_REST_BITS - 1;
       size_t sign_bit : 1;
       size_t type : 6;
+#if BITS_PER_BITS_WORD > 32
       size_t unused : (BITS_PER_BITS_WORD - 32);
+#endif
       size_t pvec_bit : 1;
       size_t mark_bit : 1;
     } bits;
diff --git a/src/pdumper.c b/src/pdumper.c
index 6fa0392b3e6..feed180e0d8 100644
--- a/src/pdumper.c
+++ b/src/pdumper.c
@@ -2236,7 +2236,17 @@ dump_finalizer (struct dump_context *ctx,
 static dump_off
 dump_bignum (struct dump_context *ctx, Lisp_Object object)
 {
-  emacs_abort ();
+  struct Lisp_Bignum *i = XBIGNUM (object);
+  struct igc_bignum_header h = { .u.word = i->header.size };
+  dump_align_output (ctx, DUMP_ALIGNMENT);
+  eassert (ctx->offset >= ctx->header.cold_start);
+  dump_off offset = ctx->offset;
+  ptrdiff_t nbytes
+      = sizeof (struct Lisp_Bignum) + h.u.bits.nlimbs * sizeof (size_t);
+  if (nbytes > DUMP_OFF_MAX)
+    error ("bignum too large");
+  dump_write (ctx, i, ptrdiff_t_to_dump_off (nbytes));
+  return offset;
 }
 #else
 static dump_off
-- 
2.39.2


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-Unbreak-64-bit-bignums.patch --]
[-- Type: text/x-diff, Size: 818 bytes --]

From 0fb8a9282f95d3c744e8305029daf3eddf154ac0 Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut@gmail.com>
Date: Wed, 8 May 2024 14:21:33 +0200
Subject: [PATCH 3/3] Unbreak 64-bit bignums

* src/igc.h (struct igc_bignum_header): Use SIZE_MAX instead of
BITS_PER_BITS_WORD.  The latter is an enum and not a macro.
---
 src/igc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/igc.h b/src/igc.h
index 85454cfd6f0..7cdaef8b96f 100644
--- a/src/igc.h
+++ b/src/igc.h
@@ -108,7 +108,7 @@ #define EMACS_IGC_H
       size_t nlimbs : PSEUDOVECTOR_SIZE_BITS + PSEUDOVECTOR_REST_BITS - 1;
       size_t sign_bit : 1;
       size_t type : 6;
-#if BITS_PER_BITS_WORD > 32
+#if SIZE_MAX > 0xffffffff
       size_t unused : (BITS_PER_BITS_WORD - 32);
 #endif
       size_t pvec_bit : 1;
-- 
2.39.2

Re: MPS: bignums

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> Ahem. The patches are attached but its doubtful that they are an improvement.

Hi Helmut, to push or not to push, ...?

Re: MPS: bignums

[Helmut Eller]

On Wed, May 08 2024, Gerd Möllmann wrote:

> Helmut Eller <eller.helmut@gmail.com> writes:
>
>> Ahem. The patches are attached but its doubtful that they are an improvement.
>
> Hi Helmut, to push or not to push, ...?

Nah.  Too radical a change.

Re: MPS: bignums

[Gerd Möllmann]

On 2024-05-08 15:13, Helmut Eller wrote:
> On Wed, May 08 2024, Gerd Möllmann wrote:
> 
>> Helmut Eller <eller.helmut@gmail.com> writes:
>>
>>> Ahem. The patches are attached but its doubtful that they are an improvement.
>>
>> Hi Helmut, to push or not to push, ...?
> 
> Nah.  Too radical a change.

Ok

Re: MPS: optimized build

[Dmitry Gutov]

On 05/05/2024 09:16, Gerd Möllmann wrote:
> In general, but I guess the wish is the father of the thought as we say
> here, Emacs seems to be, hm, snappier? Consult, vertico, corfu, ...
> completions, even typing text maybe?
> 
> Would be interesting to hear from others how they perceive it...

I've built the branch and done some measurements with

   (benchmark-run 5 (project-files (project-current)))

and it seems like the same or a little slower with smaller projects 
(less GC-intensive) and a stable improvement, about 5%, in in a larger 
one (more GC-intensive). Which seems good.

I haven't noticed a particular change in snappiness so far, but then I 
also don't usually see this problem.

Re: MPS: optimized build

[Gerd Möllmann]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 05/05/2024 09:16, Gerd Möllmann wrote:
>> In general, but I guess the wish is the father of the thought as we say
>> here, Emacs seems to be, hm, snappier? Consult, vertico, corfu, ...
>> completions, even typing text maybe?
>> Would be interesting to hear from others how they perceive it...
>
> I've built the branch and done some measurements with
>
>   (benchmark-run 5 (project-files (project-current)))
>
> and it seems like the same or a little slower with smaller projects
> (less GC-intensive) and a stable improvement, about 5%, in in a larger
> one (more GC-intensive). Which seems good.
>
> I haven't noticed a particular change in snappiness so far, but then I
> also don't usually see this problem.

Thanks!

Interesting anecdote, maybe: I think I mentioned that have an Org file
in which GCs happened so often that it was basically unusable. This Org
file behaved much much better with MPS. Almost normal.

In the end, I found out today, that this isn't from Org, at least
directly. It is caused by bug-reference-mode, somehow. Bug submitted.

Re: MPS: optimized build

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>,  Eli Zaretskii <eliz@gnu.org>,
>   Helmut Eller <eller.helmut@gmail.com>
> Date: Mon, 06 May 2024 09:03:48 +0200
> 
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
> > On 05/05/2024 09:16, Gerd Möllmann wrote:
> >> In general, but I guess the wish is the father of the thought as we say
> >> here, Emacs seems to be, hm, snappier? Consult, vertico, corfu, ...
> >> completions, even typing text maybe?
> >> Would be interesting to hear from others how they perceive it...
> >
> > I've built the branch and done some measurements with
> >
> >   (benchmark-run 5 (project-files (project-current)))
> >
> > and it seems like the same or a little slower with smaller projects
> > (less GC-intensive) and a stable improvement, about 5%, in in a larger
> > one (more GC-intensive). Which seems good.
> >
> > I haven't noticed a particular change in snappiness so far, but then I
> > also don't usually see this problem.
> 
> Thanks!
> 
> Interesting anecdote, maybe: I think I mentioned that have an Org file
> in which GCs happened so often that it was basically unusable. This Org
> file behaved much much better with MPS. Almost normal.

Indeed, the comparisons in this case should be against code that
produces a lot of garbage, not against code that is performance-heavy.

Re: MPS: optimized build

[Dmitry Gutov]

On 06/05/2024 14:49, Eli Zaretskii wrote:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Emacs Devel <emacs-devel@gnu.org>,  Eli Zaretskii <eliz@gnu.org>,
>>    Helmut Eller <eller.helmut@gmail.com>
>> Date: Mon, 06 May 2024 09:03:48 +0200
>>
>> Dmitry Gutov <dmitry@gutov.dev> writes:
>>
>>> On 05/05/2024 09:16, Gerd Möllmann wrote:
>>>> In general, but I guess the wish is the father of the thought as we say
>>>> here, Emacs seems to be, hm, snappier? Consult, vertico, corfu, ...
>>>> completions, even typing text maybe?
>>>> Would be interesting to hear from others how they perceive it...
>>>
>>> I've built the branch and done some measurements with
>>>
>>>    (benchmark-run 5 (project-files (project-current)))
>>>
>>> and it seems like the same or a little slower with smaller projects
>>> (less GC-intensive) and a stable improvement, about 5%, in in a larger
>>> one (more GC-intensive). Which seems good.
>>>
>>> I haven't noticed a particular change in snappiness so far, but then I
>>> also don't usually see this problem.
>>
>> Thanks!
>>
>> Interesting anecdote, maybe: I think I mentioned that have an Org file
>> in which GCs happened so often that it was basically unusable. This Org
>> file behaved much much better with MPS. Almost normal.
> 
> Indeed, the comparisons in this case should be against code that
> produces a lot of garbage, not against code that is performance-heavy.

I think when evaluating the change we would consider two questions:

- Does it make non-consing code slower? (Due to more complex object 
accounting, for example, or expensive parallel scanning).
- Does it reduce the time spent in GC when there is indeed garbage to 
collect.

I'd also ask "does it reduce pauses", but this one seems to have been 
already answered, MPS being a concurrent GC. Though there might have 
been some locking issues which could induce pauses anyway.

My scenario above is actually garbage-heavy (lots of strings generated). 
And yet the new GC is the same or slightly slower for smaller project 
scans, but faster on the largest one. Might have to do something with 
the fact that the current GC's thresholds are in absolute values, not 
percentiles of any kind.

Re: MPS: optimized build

[Dmitry Gutov]

On 06/05/2024 10:03, Gerd Möllmann wrote:
> Interesting anecdote, maybe: I think I mentioned that have an Org file
> in which GCs happened so often that it was basically unusable. This Org
> file behaved much much better with MPS. Almost normal.

Great thing to hear, extreme cases tend to be the most painful.