[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Improving EQ
From: |
Andrea Corallo |
Subject: |
Re: Improving EQ |
Date: |
Thu, 12 Dec 2024 05:50:04 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Ó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
- Re: Improving EQ, (continued)
- New "make benchmark" target, Stefan Kangas, 2024/12/12
- Re: New "make benchmark" target, Andrea Corallo, 2024/12/12
- Re: New "make benchmark" target, Pip Cet, 2024/12/12
- Re: New "make benchmark" target, Stefan Kangas, 2024/12/12
- Re: New "make benchmark" target, Andrea Corallo, 2024/12/13
Re: Improving EQ, Óscar Fuentes, 2024/12/12