From: Andrea Corallo
Sent: Thu Dec 12 10:50:04 GMT 2024
To: "Óscar Fuentes"
Cc: emacs-devel@gnu.org, Pip Cet
Subject: Re: Improving EQ
Óscar Fuentes <ofv@wanadoo.es> writes:
Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
writes:
I looked at the "new" code generated for our EQ macro, and decided that
a fix was in order. I'm therefore sending a first proposal to explain
what I think should be done, and some numbers.
This patch:
* moves the "slow path" of EQ into a NO_INLINE function
* exits early if the arguments to EQ are actually BASE_EQ
* returns quickly (after a single memory access which cannot be avoided
until we fix our tagging scheme to distinguish exotic objects from
ordinary ones) when symbols_with_pos_enabled isn't true.
The effect on the code size of the stripped emacs binary is small, but
significant: 8906336 bytes instead of 8955488 bytes on this machine.
(The effect on the code size of the emacs binary with debugging
information is much larger, reducing it from 32182000 bytes to 31125832
bytes on this system.) There is no effect on the size of the .pdmp
file, which is expected.
What's missing here is a benchmark, but unless there's a really nasty
surprise when that happens, I'm quite confident that we can improve the
code here.
I've seen too many cases where *removing* instructions (mind you,
literally removing, not changing!) made the code significantly slower.
Modern CPUs are insanely complex and combined with compilers make
intuition-based predictions even more futile.
That's why the patch needs to be benchmarked anyway.
But reading your message makes me wonder if EQ and some other "simple"
fundamental functions are not lowered by nativecomp? If not, maybe
that's a significant opportunity for improvement.
Nativecomp only compiles eq for Lisp code, the one discussed here is the
eq used in C (and bytecode).
BTW ATM nativecomp generates code with the same layout of the eq we had
in C till my last change of few weeks ago. When eq will be stable in C
I guess I'll replicate the layout for generated code for Lisp as well.
Andrea
|