Re: Crashes in "C-h h"

[Paul Eggert]

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.

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

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.

> 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 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*? :-)