From: Paul Eggert <eggert@cs.ucla.edu>
To: Pip Cet <pipcet@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Crashes in "C-h h"
Date: Thu, 4 Jul 2019 16:04:39 -0700 [thread overview]
Message-ID: <5e9b9214-4ccd-68a4-2016-7ac3ea8a06d9@cs.ucla.edu> (raw)
In-Reply-To: <CAOqdjBcGa1WOGJydooD0MimMrgQhm7w0CrpfEj0KmKTQ9p45oQ@mail.gmail.com>
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*? :-)
next prev parent reply other threads:[~2019-07-04 23:04 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-01 14:38 Crashes in "C-h h" Eli Zaretskii
2019-07-01 14:44 ` Lars Ingebrigtsen
2019-07-01 14:57 ` Eli Zaretskii
2019-07-01 15:01 ` Andreas Schwab
2019-07-01 15:27 ` Eli Zaretskii
2019-07-01 15:40 ` Pip Cet
2019-07-01 15:51 ` Pip Cet
2019-07-02 2:31 ` Eli Zaretskii
2019-07-03 2:38 ` Paul Eggert
2019-07-03 4:28 ` Eli Zaretskii
2019-07-03 21:05 ` Paul Eggert
2019-07-04 2:34 ` Eli Zaretskii
2019-07-04 7:15 ` Paul Eggert
2019-07-04 13:05 ` Eli Zaretskii
2019-07-04 20:58 ` Pip Cet
2019-07-04 23:04 ` Paul Eggert [this message]
2019-07-05 7:07 ` Pip Cet
2019-07-05 7:52 ` Eli Zaretskii
2019-07-05 8:17 ` Pip Cet
2019-07-05 8:38 ` Eli Zaretskii
2019-07-06 3:42 ` Paul Eggert
2019-07-06 7:08 ` Eli Zaretskii
2019-07-06 9:12 ` VanL
2019-07-06 14:30 ` Paul Eggert
2019-07-11 13:10 ` [OffTopic] " VanL
2019-07-04 4:50 ` Pip Cet
2019-07-02 2:20 ` Eli Zaretskii
2019-07-01 15:06 ` Robert Pluim
2019-07-01 15:29 ` Eli Zaretskii
2019-07-01 15:47 ` Andreas Schwab
2019-07-02 14:34 ` Martin
2019-07-02 14:38 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5e9b9214-4ccd-68a4-2016-7ac3ea8a06d9@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
--cc=pipcet@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.