Re: Crashes in "C-h h"

[Pip Cet]

On Thu, Jul 4, 2019 at 1:06 PM Eli Zaretskii <address@hidden> wrote:
> > Cc: address@hidden, address@hidden
> > From: Paul Eggert <address@hidden>
> > Date: Thu, 4 Jul 2019 00:15:12 -0700
> >
> > 1030-lnxsrv09 $ time ./a.out 0 0
> >
> > real  0m51.933s
> > user  0m51.927s
> > sys   0m0.001s
> > 1031-lnxsrv09 $ time ./a.out 0 0 0
> >
> > real  2m16.960s
> > user  2m16.960s
> > sys   0m0.000s
> > 1032-lnxsrv09 $ time ./a.out 0 0 0 0
> >
> > real  0m59.678s
> > user  0m59.677s
> > sys   0m0.001s
>
> Thanks.

I'm seeing a much smaller slowdown with "perf stat": 12.3 cycles/loop
rather than 11.7.

> > This indicates that on this !USE_LSB platform, the EQ+make_fixnum code is 
> > about
> > ten times faster than the FIXNUMP+XFIXNUM code on this benchmark.
>
> You mean twice faster (~2m vs ~1m), right?

"g" is 8 seconds slower than "noop", but "f" is 76 seconds slower.

> > I'm not surprised by the performance disparity, as branch-prediction
> > failures can be pretty expensive.

Do you really see mispredicted branches in this simple example? I'm surprised.

I'm seeing a single branch in "f", which is well-predicted as it
alternates between being taken and not being taken.

> Which indeed means that if the object is not guaranteed to be a
> fixnum, using XFIXNUM is generally suboptimal.

XFIXNUM is half a clock cycle more expensive, maybe, in non-equivalent
code, on a peculiar platform. That's hardly "generally".

(It is a pity that gcc doesn't optimize bit field comparisons very
well, so we have to resort to the ((x-c) & mask) == 0 construction in
TAGGEDP. Maybe we could make it better by throwing in some eassumes,
but really gcc needs to recognize (x-c) & mask == 0 as equivalent to
(x & mask) == c (in the right conditions) and emit whichever variant
is faster.)

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, but it would reduce our dependencies on the
fixnum range being large enough to hold all practical integers.