From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: Improving EQ Date: Thu, 12 Dec 2024 05:50:04 -0500 Message-ID: References: <87h679kftn.fsf@protonmail.com> <87ttb9xjvb.fsf@telefonica.net> 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="26439"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: , Pip Cet To: =?utf-8?Q?=C3=93scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 12 11:50:50 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 1tLgmQ-0006ep-EU for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Dec 2024 11:50:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLglm-0002gY-9Y; Thu, 12 Dec 2024 05:50:10 -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 1tLgli-0002gG-PZ for emacs-devel@gnu.org; Thu, 12 Dec 2024 05:50:07 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tLglh-0005qe-8O; Thu, 12 Dec 2024 05:50:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=h6N1YLwpcws++URAhcQXVcxeqwF4XftgQcroTSvmqAc=; b=ZBP/6qDmdX8yC36K7OLg UvqTPcD33hy4W5ELZodjAbmORb2E5MC2RE0qED2rPrUsfdcwhrlUzpAZx56qogpA4cwx6+c3FdB4a M+UfklGMEizSPC8vTp+/P/woaJH/AbrN2+sto+0fIibyNaw2pWPeCuJ20pyjYMa55NDb3iFuIeBhD 7wviDfjsRpR8dYNxsndyP3VgVT2E0xDDlkywJt2TjyiNp1c+ay7nr9PmGAGwleHx8xr4RDBr3Dt6V 61Lu8eHHj+ujibh4guOsPx4SwcbO/fr43RiTrZwOTHPd97NssnqnXqg5JM1sCtkSb3ff8Wlv/W+Ml mjaoelH2M0n6DA==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1tLglg-0004KF-TT; Thu, 12 Dec 2024 05:50:04 -0500 In-Reply-To: <87ttb9xjvb.fsf@telefonica.net> (=?utf-8?Q?=22=C3=93scar?= Fuentes"'s message of "Thu, 12 Dec 2024 11:42:48 +0100") 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:326422 Archived-At: =C3=93scar Fuentes writes: > Pip Cet via "Emacs development discussions." > writes: > >> I looked at the "new" code generated for our EQ macro, and decided that >> a fix was in order. I'm therefore sending a first proposal to explain >> what I think should be done, and some numbers. >> >> This patch: >> * moves the "slow path" of EQ into a NO_INLINE function >> * exits early if the arguments to EQ are actually BASE_EQ >> * returns quickly (after a single memory access which cannot be avoided >> until we fix our tagging scheme to distinguish exotic objects from >> ordinary ones) when symbols_with_pos_enabled isn't true. >> >> The effect on the code size of the stripped emacs binary is small, but >> significant: 8906336 bytes instead of 8955488 bytes on this machine. >> (The effect on the code size of the emacs binary with debugging >> information is much larger, reducing it from 32182000 bytes to 31125832 >> bytes on this system.) There is no effect on the size of the .pdmp >> file, which is expected. >> >> What's missing here is a benchmark, but unless there's a really nasty >> surprise when that happens, I'm quite confident that we can improve the >> code here. > > I've seen too many cases where *removing* instructions (mind you, > literally removing, not changing!) made the code significantly slower. > > Modern CPUs are insanely complex and combined with compilers make > intuition-based predictions even more futile. That's why the patch needs to be benchmarked anyway. > But reading your message makes me wonder if EQ and some other "simple" > fundamental functions are not lowered by nativecomp? If not, maybe > that's a significant opportunity for improvement. Nativecomp only compiles eq for Lisp code, the one discussed here is the eq used in C (and bytecode). BTW ATM nativecomp generates code with the same layout of the eq we had in C till my last change of few weeks ago. When eq will be stable in C I guess I'll replicate the layout for generated code for Lisp as well. Andrea