emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] master f18af6c: Audit use of lsh and fix glitches


From: Paul Eggert
Subject: Re: [Emacs-diffs] master f18af6c: Audit use of lsh and fix glitches
Date: Sat, 25 Aug 2018 14:24:15 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

Pip Cet wrote:

I'm already using a separate tag value for bignums, though it might
help to use tag value 0 instead of a nonzero one (but then Qnil
couldn't be all-zeroes in memory).

We'd have to measure it, as there is also a benefit when NILP and initialization to Qnil are fast.

I've discovered that the sequence gcc (trunk) emits for a mask-and-compare is:
     mov %rax, %rbx
     and $7, %rbx
     cmp $7, %rbx
where I would use
     lea 1(%rax), %ebx
     test $7, %bl

I can force the latter by testing ((char)((int)(XLI (x) + 8 -
Lisp_String)) & 7) == 0 rather than the (equivalent, AFAICS) (XLI (x)
& 7) == Lisp_String (sometimes gcc uses a longer sequence, though). At
this point, I think gcc should be emitting the shorter two-insn
sequence for both C expressions.

I agree, and filed a GCC bug report about it, here:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87104

With this "improvement", the code size difference is 13184 bytes. I'm
unable to measure a performance difference, since it is lost in the
noise.

I tried a similar microoptimization on the Emacs trunk, and it made Emacs about 0.4% faster on my platform. This seems like a clear win pretty much everywhere, regardless of what we do about eq vs eql, so I installed the attached patch into master.

I've benchmarked the hash-cons approach, though the implementation I
used was rather trivial, and simple bignum calculations appear to be
about 20-50% slower. Again, I expect that number to increase once the
extra copy in make_number is removed. (For floats, the slowdown is
worse.)

Ouch. These figures are making me more inclined to stick with what we have in master, namely the Common Lisp and Scheme tradition that eq is a finer comparison operation than eql is, when these comparisons are applied to bignums and/or to floats. Of course we can continue to guarantee the traditional eq semantics on fixnums.

Attachment: 0001-Improve-performance-of-CONSP-FIXNUMP-etc.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]