all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Andrea Corallo <acorallo@gnu.org>
To: Pip Cet <pipcet@protonmail.com>
Cc: Emacs Devel <emacs-devel@gnu.org>
Subject: Re: __builtin_expect
Date: Thu, 28 Nov 2024 11:12:23 -0500	[thread overview]
Message-ID: <yp1serbgwwo.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <vV3jtkqOvSKL3pMTe_xgrUMBdZo5QjlyU2cuAsZlMImf6SFOtBfXiA_x9m7O9nAg8uhVpv9WylGYEJy2XioSQZZksCcT_N7TdZlBdZIJQoI=@protonmail.com> (Pip Cet's message of "Thu, 28 Nov 2024 15:45:46 +0000")

Pip Cet <pipcet@protonmail.com> writes:

> On Thursday, November 28th, 2024 at 15:02, Andrea Corallo <acorallo@gnu.org> wrote:
>> Pip Cet pipcet@protonmail.com writes:
>> > On Thursday, November 28th, 2024 at 10:35, Andrea Corallo acorallo@gnu.org wrote:
>> > 
>> > > branch: master
>> > > commit b0ba0d42b0fdf70a20cd7a070128db8abe4a0826
>> > > Author: Andrea Corallo acorallo@gnu.org
>> > > 
>> > > Commit: Andrea Corallo acorallo@gnu.org
>> > > 
>> > > * src/lisp.h (EQ): Improve generated code.
>> > > 
>> > > Outside compilation 'symbols_with_pos_enabled' is always false, so ask
>> > > the compiler to organize the most likely execution path in a sequential
>> > > fashion in order to favor run-time performance.
>> > 
>> > Are we officially using __builtin_expect now?
>> 
>> config.h AFAIU defines it to a nop if the compiler does not support it.
>
> It does, thanks!
>
> I'm not sure that isn't a mere accident, though: currently, gnulib
> pulls in the builtin-expect module because it's used by gnulib
> internally, not because we explicitly requested it. If we want to use
> __builtin_expect in general, not just for special configurations
> (Android), we need to tell gnulib to pull in the `builtin-expect'
> module.
>
> IOW, config.h isn't part of the Emacs sources, and whether it includes
> a section from builtin-expect.m4 depends on gnulib internals that may
> change without notice. We're talking about a compiler "feature" that
> the GCC manual advises us not to use, so I think that's a possibility.

If you feel this need to be fixed could you please submit a patch?

> But even if we can rely on the existence of the macro, "happens to be available" is not the same as "officially something we use". I still think it's a major decision, and needs to be discussed.

It was already in use in the Emacs code-base before my commit, and I
don't see any specific reason why we should not use it where deemed to
be useful.  I'm not a fan at all of the spread use of manually annotated
branches, but this case is pretty obvious and important at the same
time.

>> > I think that's a major change to the way Emacs C code is written, and a decision which might benefit from further discussion.
>> > 
>> > To quote the GCC manual:
>> > In general, you should prefer to use actual profile feedback for this (-fprofile-arcs), as programmers are notoriously bad at predicting how their programs actually perform.
>> > 
>> > Maybe we should use __builtin_expect_with_probability instead, in
>> > those rare cases when we are certain we're making a correct
>> > prediction? Or, my preference, avoid using __builtin_expect entirely,
>> > so our scarce resources can be spent on more important issues?
>> > 
>> > I also don't think the assumption you're telling GCC to make in this specific case (more than 90% of calls to EQ happen while syms_with_pos_enabled == false) is obviously correct.
>> 
>> I think it is correct when we are not compiling, and as mentioned in the
>> commit msg that's the case the patch is optimizing for.
>
> The code isn't specific to "when we are not compiling", and the compiler won't read your commit message.

I don't understand sorry, no compiler is reading commit messages, but
people commenting on emacs-devel should.

  Andrea



  reply	other threads:[~2024-11-28 16:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-28 15:45 __builtin_expect (was: Re: master b0ba0d42b0f: * src/lisp.h (EQ): Improve generated code.) Pip Cet via Emacs development discussions.
2024-11-28 16:12 ` Andrea Corallo [this message]
2024-11-28 20:29   ` __builtin_expect Pip Cet via Emacs development discussions.
2024-11-28 21:32     ` __builtin_expect Andrea Corallo
2024-11-28 22:06       ` __builtin_expect Pip Cet via Emacs development discussions.
2024-11-29  7:19       ` __builtin_expect 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=yp1serbgwwo.fsf@fencepost.gnu.org \
    --to=acorallo@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=pipcet@protonmail.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.