From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Improving EQ Date: Thu, 12 Dec 2024 11:18:16 +0200 Message-ID: <868qsl1cpz.fsf@gnu.org> References: <87h679kftn.fsf@protonmail.com> <86frmt1k6w.fsf@gnu.org> <871pydjo23.fsf@protonmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2624"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mattiase@acm.org, eggert@cs.ucla.edu, emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 12 10:19:30 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 1tLfM1-0000Sd-Tq for ged-emacs-devel@m.gmane-mx.org; Thu, 12 Dec 2024 10:19:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLfLP-0002n9-7b; Thu, 12 Dec 2024 04:18:52 -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 1tLfLD-0002eR-KD for emacs-devel@gnu.org; Thu, 12 Dec 2024 04:18:43 -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 1tLfLC-00013v-GQ; Thu, 12 Dec 2024 04:18:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=7rfocCVZOov5KHjwNZnWwEMZOtAn31yMT+DND7oYNq4=; b=QKhkduzHnrGL4guZUGqv lIZM74qgVjYhWjsayloE6iSyCsPab9MRkcRXgvbr4NOWw0o35byQ/9KAVJwlm80bojJkoiQT3UCIg U150ds81PmiX+4bCfGd9rzpniXFgEV/Z8z3us99e+JnWxHhq0vZlsYEIEE3FZAn6X8BzYTkxP8Ff1 S5J8utKRnGUOtFchmCz8ZMxJe551V/3rMRMi6CrG3CI0WiVcQwkNJCLraXP2X4BJQ55KiCyDCJqF0 8n/z00lbr+jm2LzEKtpnTVbgPmTU022Nx+Y0htxkY7PHKUtDHjXWUVu9M6WPmYixCWFORzQCwTB3I wqhVtnKQHMuzgw==; In-Reply-To: <871pydjo23.fsf@protonmail.com> (message from Pip Cet on Thu, 12 Dec 2024 08:36:50 +0000) 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:326413 Archived-At: > Date: Thu, 12 Dec 2024 08:36:50 +0000 > From: Pip Cet > Cc: Mattias Engdegård , Paul Eggert , emacs-devel@gnu.org > > "Eli Zaretskii" writes: > > > The usual easy benchmark is to byte-compile all the *.el files in the > > source tree. That is, remove all the *.elc files, then say "make" and > > time that. > > Considering the point of the optimization was to make compilation (when > symbols_with_pos_enabled is true) slower, but speed up non-compilation > use cases, I think that may be the opposite of what we want :-) That's fine, because knowing where this slows us down and by how much is also important. > Furthermore, the master branch doesn't currently build after deleting > all the *.elc files, because recompilation exceeds max-lisp-eval-depth > in that scenario (together with the known purespace issue, this pretty > much means "make bootstrap" is the only way I can rebuild an emacs tree > right now. It'd be great if Someone could look into this, but I've > failed to understand the native-compilation code (and been told off for > trying to) too often for that Someone to be me. Plus, of course, I fully > understand that native compilation currently has wrong code generation > bugs which obviously have to take priority over build issues...) If this is with native-compilation, how about trying without? Also, enlarging max-lisp-eval-depth (assuming you don't somehow hit infinite recursion) locally should be easy: just add that to the relevant Makefiles. > https://elpa.gnu.org/packages/elisp-benchmarks.html ? It'd be great if > we could agree on a benchmark, and even better if there were a way to > reliably run it from emacs -Q :-) Our benchmark facilities are very rudimentary, so agreement is not an issue: we just use whatever is available. > In fact, I would suggest to move a reduced benchmark suite to the emacs > repo itself, and run it using "make benchmark". Working on a better benchmark is very useful, but maybe we should try solving one problem at a time? > Also, just to let everyone know, I'm planning to make the "exotic" > property (this object must or can use the slow_eq path) part (probably > the LSB) of the tag rather than accessing it via a global variable and > the PVEC type. This should reduce code size further, should speed up > things, and has some other advantages which I'll go into when I have > working code. Whenever you change something in the tags, please remember to update .gdbinit, otherwise we lose debugging support.