[Top][All Lists]

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

Re: Crashes in "C-h h"

From: Paul Eggert
Subject: Re: Crashes in "C-h h"
Date: Thu, 4 Jul 2019 16:04:39 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2

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 

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

reply via email to

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