Re: Crashes in "C-h h"

[Pip Cet <pipcet@gmail.com>]

On Thu, Jul 4, 2019 at 11:04 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> Pip Cet wrote:
>
> > I'm seeing a much smaller slowdown with "perf stat": 12.3 cycles/loop
> > rather than 11.7.
>
> It very much depends on the CPU. I got results all over the map when I used
> different CPUs. Sometimes there wasn't that much difference, sometimes more than
> what I mentioned. FIXNUMP+XFIXNUM was always slower than EQ+make_fixnum, though.

I don't see how it can be any faster. The code generated by
EQ+make_fixnum seems optimal to me, and the code for even an optimal
version of FIXNUMP+XFIXNUM would have to sign-extend the INTMASK bits
first.

> >> You mean twice faster (~2m vs ~1m), right?
> >
> > "g" is 8 seconds slower than "noop", but "f" is 76 seconds slower.

Oops, I should have said "again", here.

> My calculations have "f" 85 not 76 seconds slower, which means FIXNUMP+XFIXNUM
> was about 11x slower (10.972x times slower, to be absurdly precise).

> > I'm seeing a single branch in "f", which is well-predicted as it
> > alternates between being taken and not being taken.
>
> Maybe my CPU isn't using 2-bit branch prediction for this case, whereas yours is.

Maybe. Looking at the assembler code next to "perf stat" output would
be one way to find out (if you're running Linux).

> > gcc needs to recognize (x-c) & mask == 0 as equivalent to
> > (x & mask) == c (in the right conditions) and emit whichever variant
> > is faster.)
>
> Yes, this is the GCC performance bug I reported about a year ago
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87104>. You came up with a GCC
> patch which you labeled "WIP". Maybe it's time to get that patch out the door?

I sent the patch to gcc-patches, got no response, and then my old
computer broke, so part of the patch is now untestable.

I get the impression the GCC folks barely even get around to important
bug reports, so micro-optimization is probably a low priority.

> > I think it would make most sense to introduce a macro for comparing a
> > Lisp object to a C integer, which does the right thing even outside
> > the fixnum range. Slower, ...
>
> All this talk about optimization, and now you want things to be *slower*? :-)

I doubt it's actually going to be slower, since memory access to the
data probably dominates whatever register operations we do. The
important thing is not to have mispredicted branches...

Anyway, is there any reason not to have an assert in make_fixnum to
make sure the number fits?