Removing pure space

Removing pure space

[Pip Cet]

I believe it is time to remove pure space from Emacs 28. It's a
needless complication which no longer provides clear gains. On the
other hand, it has clear disadvantages now that pdumper has become the
standard dumper: we end up putting about 3 megabytes of zero bytes
into each Emacs executable on GNU/Linux systems, for example.

Furthermore, the pure space code, even though it has been with us so
long, still has issues: see bug#46916 for one.

Most importantly, though, pure space requires a lot of complicated
code in places that are very hairy and difficult to modify; for
example, any change to the garbage collector has to be careful to
handle this special case correctly and (to the extent that this is
even possible) efficiently.

I am linking to a rebased patch which removes pure space from Emacs
28. It does not remove purecopy, it just modifies that function to
perform hash consing of values without purifying them:

https://lists.gnu.org/archive/html/bug-gnu-emacs/2021-03/msg00335.html

Further steps would be to redefine purecopy to be a no-op, remove
calls to it from existing code, and finally to remove it
entirely. Those steps are not urgent, though.

Please note that this is almost entirely independent of any plans or
discussions to remove unexec support or require pdumper. When I last
looked into this issue, the Emacs 28 tree would not build with unexec
support, but, once modified to do so, it built just fine with the pure
space removal patch applied.

I have not been able to measure any performance changes with this
patch applied, but unfortunately I'm currently on a system unsuitable
for running reliable benchmarks. If this is a concern, any help
measuring the performance impact more accurately would be appreciated.

So, is anyone going to speak up to defend pure space?

Once that is settled, we can look at the actual patch and see whether
I made any mistakes in removing pure space.

Pip

Re: Removing pure space

[Stefan Monnier]

> I have not been able to measure any performance changes with this
> patch applied, but unfortunately I'm currently on a system unsuitable
> for running reliable benchmarks. If this is a concern, any help
> measuring the performance impact more accurately would be appreciated.

The main expected benefit from the purespace is that the GC doesn't need
to look at it, so the GC should be faster because it looks at a smaller
part of the heap.

So I think a good micro-benchmark which should expose the worst-case
impact of removing the purespace would be to compare the time taken to
perform GC (I think the effect should be most visible right at startup
since the more packages and stuff you have loaded, the smaller the
proportion of the heap kept in purespace).


        Stefan

Re: Removing pure space

[Pip Cet]

On Thu, Mar 4, 2021 at 2:49 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > I have not been able to measure any performance changes with this
> > patch applied, but unfortunately I'm currently on a system unsuitable
> > for running reliable benchmarks. If this is a concern, any help
> > measuring the performance impact more accurately would be appreciated.
>
> The main expected benefit from the purespace is that the GC doesn't need
> to look at it, so the GC should be faster because it looks at a smaller
> part of the heap.

With pdumper, I don't think that's true anymore. There are three Lisp
objects for which PURE_P returns true: the empty vector, unibyte
string, and multibyte string.

In fact, if anything, it'll be slower because of the extra overhead of
the PURE_P checks...

> So I think a good micro-benchmark which should expose the worst-case
> impact of removing the purespace would be to compare the time taken to
> perform GC (I think the effect should be most visible right at startup
> since the more packages and stuff you have loaded, the smaller the
> proportion of the heap kept in purespace).

So you're saying I should build with unexec, then run something like:

"time ./emacs --batch --eval '(dotimes (i 10000) (garbage-collect))'

? Because I don't really think that benchmark makes sense with pdumper...

Pip

Re: Removing pure space

[Pip Cet]

On Thu, Mar 4, 2021 at 2:55 PM Pip Cet <pipcet@gmail.com> wrote:
> On Thu, Mar 4, 2021 at 2:49 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> > > I have not been able to measure any performance changes with this
> > > patch applied, but unfortunately I'm currently on a system unsuitable
> > > for running reliable benchmarks. If this is a concern, any help
> > > measuring the performance impact more accurately would be appreciated.
> >
> > The main expected benefit from the purespace is that the GC doesn't need
> > to look at it, so the GC should be faster because it looks at a smaller
> > part of the heap.
>
> With pdumper, I don't think that's true anymore. There are three Lisp
> objects for which PURE_P returns true: the empty vector, unibyte
> string, and multibyte string.
>
> In fact, if anything, it'll be slower because of the extra overhead of
> the PURE_P checks...
>
> > So I think a good micro-benchmark which should expose the worst-case
> > impact of removing the purespace would be to compare the time taken to
> > perform GC (I think the effect should be most visible right at startup
> > since the more packages and stuff you have loaded, the smaller the
> > proportion of the heap kept in purespace).
>
> So you're saying I should build with unexec, then run something like:
>
> "time ./emacs --batch --eval '(dotimes (i 10000) (garbage-collect))'
>
> ? Because I don't really think that benchmark makes sense with pdumper...

2590983 pure bytes used

Okay. I've just sacrificed several small animals (one of them kept
screaming DO NOT EDIT! GENERATED AUTOMATICALLY!) in order to build
emacs with unexec one final time. Two final times, in fact, with and
without my patch.

And here I was going to gloat about how there's no measurable
difference, but there is. It's faster by about a millisecond per
(garbage-collect) call, or about 30% of the time that loop takes.

Again, though, that's only compared to unexec, which hasn't built
since Paul merged my eager hash table rehashing patch quite some time
ago, and isn't trivial to build even with that fixed.

Pip

Re: Removing pure space

[Stefan Monnier]

>> > I have not been able to measure any performance changes with this
>> > patch applied, but unfortunately I'm currently on a system unsuitable
>> > for running reliable benchmarks. If this is a concern, any help
>> > measuring the performance impact more accurately would be appreciated.
>> The main expected benefit from the purespace is that the GC doesn't need
>> to look at it, so the GC should be faster because it looks at a smaller
>> part of the heap.
> With pdumper, I don't think that's true anymore.

Notice I did not say that this is the benefit you get.
Only that's the benefit that is expected from it.  IOW the statement is still
true even if purespace just makes everything worse.


        Stefan

Re: Removing pure space

[Stefan Monnier]

> I believe it is time to remove pure space from Emacs 28.

Agreed!

Now that pdump has removed the main benefit of the purespace, there's no
good reason to keep that extra complexity.  Removing it will allow some
simplifications in the code which should even lead to slight
performance improvements.


        Stefan