From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: __builtin_expect Date: Thu, 28 Nov 2024 20:29:53 +0000 Message-ID: <-RjfswKL3C48Xb5i4UIUxCjnwRceVcJLWbxPqC118LgFluGk1pC9nPnX7uvy2pfLr9_tIT4c6LRO47ggVIB5_jw91LHlu4SrGGkJYOd4j8k=@protonmail.com> References: Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26342"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs Devel To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 29 07:55:12 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tGuuG-0006fV-7H for ged-emacs-devel@m.gmane-mx.org; Fri, 29 Nov 2024 07:55:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tGutb-0003je-U2; Fri, 29 Nov 2024 01:54:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tGl9O-0006sw-OU for emacs-devel@gnu.org; Thu, 28 Nov 2024 15:30:10 -0500 Original-Received: from mail-40133.protonmail.ch ([185.70.40.133]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tGl9F-0008Cn-Hz for emacs-devel@gnu.org; Thu, 28 Nov 2024 15:30:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1732825797; x=1733084997; bh=XlHv5OLejdK8m+6QgFdQSYvBq3aqwiukYDoC6rZ431g=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=h+01pr6QsXRT0a5CteEF6HzHqLuwZAxrtLlVD8PBPzrQjyM9/K8XTdyrVDu00H7X1 sNeMcpHBlXbyYmm0jtdfBD/xhQrGXyQ1aSxN5Y3PDIYH9dfdJp6QlEGAtlq1SeZ3d/ 0mfja1u6H93jr8LbsmO7F9yYLoRBfWgdFwywkFBtnB8HUekuuxU0IYNVoXrg77jaW1 i7t5I/rDkIcZ6HD9WZtnpCNZSkqPKJku536APC5Y+6zS/fmh1rsRw09e54Ho9JPxWC AqIVXwHagLVN/OUV0T3azha5sQmK+gJ0ovH77gvsl8V7/ZPUYqdAXaCCXMOlDhES0S se15fJywlBqLw== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: cfdc441c172751b89b7966d5d9c824abd8ca6083 Received-SPF: pass client-ip=185.70.40.133; envelope-from=pipcet@protonmail.com; helo=mail-40133.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 29 Nov 2024 01:54:28 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:325840 Archived-At: On Thursday, November 28th, 2024 at 16:12, Andrea Corallo wrote: > Pip Cet pipcet@protonmail.com writes: >=20 > > On Thursday, November 28th, 2024 at 15:02, Andrea Corallo acorallo@gnu.= org wrote: > >=20 > > > Pip Cet pipcet@protonmail.com writes: > > >=20 > > > > On Thursday, November 28th, 2024 at 10:35, Andrea Corallo acorallo@= gnu.org wrote: > > > >=20 > > > > > branch: master > > > > > commit b0ba0d42b0fdf70a20cd7a070128db8abe4a0826 > > > > > Author: Andrea Corallo acorallo@gnu.org > > > > >=20 > > > > > Commit: Andrea Corallo acorallo@gnu.org > > > > >=20 > > > > > * src/lisp.h (EQ): Improve generated code. > > > > >=20 > > > > > Outside compilation 'symbols_with_pos_enabled' is always false, s= o ask > > > > > the compiler to organize the most likely execution path in a sequ= ential > > > > > fashion in order to favor run-time performance. > > > >=20 > > > > Are we officially using __builtin_expect now? > > >=20 > > > config.h AFAIU defines it to a nop if the compiler does not support i= t. > >=20 > > It does, thanks! > >=20 > > 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. > >=20 > > 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. >=20 > If you feel this need to be fixed could you please submit a patch? To enable __builtin_expect, or to remove it? I think for now we should do t= he latter. > > But even if we can rely on the existence of the macro, "happens to be a= vailable" is not the same as "officially something we use". I still think i= t's a major decision, and needs to be discussed. >=20 >=20 > It was already in use in the Emacs code-base before my commit, You mean the two usages in src/android.c? We don't support arbitrary compil= ers for Android code, only clang (and maybe GCC again if that has been fixe= d), so that's hardly precedent to build on when modifying lisp.h. > and I > don't see any specific reason why we should not use it where deemed to > be useful. At the very least, we'd need to establish it actually is useful. Going by i= ntuition isn't the right answer here. > 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. It's not obvious to me, sorry. > > > > I think that's a major change to the way Emacs C code is written, a= nd a decision which might benefit from further discussion. > > > >=20 > > > > To quote the GCC manual: > > > > In general, you should prefer to use actual profile feedback for th= is (-fprofile-arcs), as programmers are notoriously bad at predicting how t= heir programs actually perform. > > > >=20 > > > > 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 entirel= y, > > > > so our scarce resources can be spent on more important issues? > > > >=20 > > > > I also don't think the assumption you're telling GCC to make in thi= s specific case (more than 90% of calls to EQ happen while syms_with_pos_en= abled =3D=3D false) is obviously correct. > > >=20 > > > 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. > >=20 > > The code isn't specific to "when we are not compiling", and the compile= r won't read your commit message. >=20 > I don't understand sorry, no compiler is reading commit messages, but You said that your assumption holds "when we are not compiling", but your c= ode change applies to the other case, too. Pip