[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Crashes in "C-h h"
From: |
Pip Cet |
Subject: |
Re: Crashes in "C-h h" |
Date: |
Thu, 4 Jul 2019 20:58:22 +0000 |
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.
- Re: Crashes in "C-h h", (continued)
- Re: Crashes in "C-h h", Eli Zaretskii, 2019/07/01
- Re: Crashes in "C-h h", Pip Cet, 2019/07/01
- Re: Crashes in "C-h h", Pip Cet, 2019/07/01
- Re: Crashes in "C-h h", Eli Zaretskii, 2019/07/01
- Re: Crashes in "C-h h", Paul Eggert, 2019/07/02
- Re: Crashes in "C-h h", Eli Zaretskii, 2019/07/03
- Crashes in "C-h h", Paul Eggert, 2019/07/03
- Re: Crashes in "C-h h", Eli Zaretskii, 2019/07/03
- Re: Crashes in "C-h h", Paul Eggert, 2019/07/04
- Re: Crashes in "C-h h", Eli Zaretskii, 2019/07/04
- Re: Crashes in "C-h h",
Pip Cet <=
- Re: Crashes in "C-h h", Paul Eggert, 2019/07/04
- Re: Crashes in "C-h h", Pip Cet, 2019/07/05
- Re: Crashes in "C-h h", Eli Zaretskii, 2019/07/05
- Re: Crashes in "C-h h", Pip Cet, 2019/07/05
- Re: Crashes in "C-h h", Eli Zaretskii, 2019/07/05
- Re: Crashes in "C-h h", Paul Eggert, 2019/07/05
- Re: Crashes in "C-h h", Eli Zaretskii, 2019/07/06
- Re: Crashes in "C-h h", VanL, 2019/07/06
- Re: Crashes in "C-h h", Paul Eggert, 2019/07/06
- [OffTopic] Re: Crashes in "C-h h", VanL, 2019/07/11