Re: MPS: weak hash tables

[Pip Cet]

On Saturday, July 6th, 2024 at 17:28, Gerd Möllmann <gerd.moellmann@gmail.com> 
wrote:
> Pip Cet pipcet@protonmail.com writes:
> 
> > > We have already this in bignum.c
> > > 
> > > mp_set_memory_functions (xmalloc, xrealloc_for_gmp, xfree_for_gmp);
> > > 
> > > Haven't read the GMP docs yet, but that looks like something that could
> > > be used.
> > 
> > Patch attached, couldn't resist :-)
> 
> 
> Haha :-). I'm all for it!
> 
> > Memory usage is perfectly acceptable with this patch, but it does do a
> > lot of GC.
> 
> 
> What do the timings say?

Horrible things. Unacceptably slow. Sufficiently so that I looked into the 
generation parameters and randomly changed them, and now it's faster than 
vanilla Emacs?! Does that make sense to you, or is it more likely I'm being 
tricked by something silly like CPU speed?

All I did was change:

-  mps_gen_param_s gens[] = { { 128000, 0.8 }, { 5 * 128000, 0.4 } };
+  mps_gen_param_s gens[] = { { 64000, 0.8 }, { 5 * 64000, 0.4 }, { 10 * 64000, 
0.3 }, };

but that was a totally random guess...

Again, I may just be doing something wrong.

> > > > I believe Eli is right, though, that we should deviate from what Emacs
> > > > usually does as little as possible until we've got things working.
> > > > That means just keeping track of how much we've allocated and calling
> > > > garbage_collect via maybe_garbage_collect, I think.
> > 
> > > Can you explain? I mean I agree in general, but in this case I'm not so
> > > sure. What I've currently implemented is basically a function of the
> > > number of allocated finalizable objects and only finalizable objects pay
> > > the price. The size of allocated memory overall, i.e. counting the bytes
> > > in alloc_impl doesn't contain the information.
> > 
> > But it's probably a better indicator of how much GC activity happened,
> > and that influences how many finalization messages there would be,
> > assuming that an approximately constant percentage of objects is
> > finalizable...
> 
> 
> Hm. I'm not really convinced the total amount allocated is a better
> predictor for how many finalzation msgs we might expect than the real
> number of objects for which we might expect finalization messages.

Now that you put it like that, maybe the case I've been worrying about (phase 
one of the program creates a huge number of live finalizable objects; phase two 
stops creating them; finalizable objects never get finalized because no new 
ones are being created) isn't that likely. Anyway, your code works, so it wins 
:-)

> But whatever. Something for later, maybe.

Definitely.

Pip