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: Improving EQ Date: Thu, 12 Dec 2024 17:05:32 +0000 Message-ID: <87ikroj0ic.fsf@protonmail.com> References: <87h679kftn.fsf@protonmail.com> <87ttb9xjvb.fsf@telefonica.net> 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="2614"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?utf-8?Q?=C3=93scar_Fuentes?= , emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 12 19:50:10 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 1tLoGI-0000WH-Cn for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Dec 2024 19:50:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLoFg-0002D1-BS; Thu, 12 Dec 2024 13:49:32 -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 1tLmdC-00019A-1s for emacs-devel@gnu.org; Thu, 12 Dec 2024 12:05:42 -0500 Original-Received: from mail-4322.protonmail.ch ([185.70.43.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tLmd8-0002xw-Om for emacs-devel@gnu.org; Thu, 12 Dec 2024 12:05:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1734023135; x=1734282335; bh=JwpybCQoc5VFjhAo6DrH+1D2M1dVETVB+Pw7xrrRN0Y=; 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=JfS6USTnDdEJahbjbHA9OXfjel38ITN0W1DKnMuyNJ8a4eTg1PwOaTDTAXO698jCm pfPXuPnVxlUGChRYY/l/2zaHYRLuv9CSyfyHgfvtYWsjFh5RP9ZOiUmOI47T7RpIZt 5FMLVu5RIy24JeLU0K/gp2OY9xmxh0dObig5l9Cjt9iMDE1ptbFEeq4gOlubj6QC5W DXa3xnqyvqxneMSOvj3tXvw+80InD1z5lwHwgXmtVPpb9de8IapCBwHKnCQad2v6Uk MoKdxaIUQ/EpWlstooOCw88zjmVrYAZ6UCZ0W2+aB8iYw6ZjBGF1UAodr2i+WfxqIF 3Ybsargg/Ggvg== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 13877b19f685ba9c06df5d378eaf6423f271d90e Received-SPF: pass client-ip=185.70.43.22; envelope-from=pipcet@protonmail.com; helo=mail-4322.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_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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: Thu, 12 Dec 2024 13:49:26 -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:326436 Archived-At: "Andrea Corallo" writes: > =C3=93scar Fuentes writes: >> I've seen too many cases where *removing* instructions (mind you, >> literally removing, not changing!) made the code significantly slower. Yes, there are many ways in which that can happen. Removing prefetches or branch hints is the most obvious example, but I don't claim to know all the ways, and ultimately if an expected performance improvement does not materialize we might have to decide this one on code size reasons alone (of course, if performance is drastically worse, we shouldn't apply the patch). >> Modern CPUs are insanely complex and combined with compilers make >> intuition-based predictions even more futile. The compiler isn't the issue here, since I checked the assembly code that was generated. Totally agree about CPUs. For example, moving code out of line will change many conditional branch locations to a single one (the one in the out-of-line function), which may help or hurt branch prediction, and that's just one of many ways in which inline functions often lose. So we should also benchmark whether this might be one of those cases, in which case we'd want to move all of EQ to a non-inlined function... > That's why the patch needs to be benchmarked anyway. Absolute agreement there. I tried some initial benchmarks and it's lost in the noise, but that was while running on battery on a laptop, and I need to test on a machine with a proper fixed clock rate. >> 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. Thanks, that would be great. Yes, it makes most sense to test with and without nativecomp, expecting improvement to be more significant in the latter case (but as EQ is used by C code used by native-compiled Lisp, I expect a small improvement there, too). Pip