From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Time to merge scratch/correct-warning-pos into master, perhaps? Date: Fri, 25 Feb 2022 22:29:01 +0000 Message-ID: References: <838ruq2z5t.fsf@gnu.org> <83v8xt20db.fsf@gnu.org> <83ee4gyzrh.fsf@gnu.org> <83v8xryh4d.fsf@gnu.org> <831qzyzt5t.fsf@gnu.org> 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="21811"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, mattiase@acm.org, gregory@heytings.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 25 23:54:59 2022 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 1nNjUJ-0005U3-7a for ged-emacs-devel@m.gmane-mx.org; Fri, 25 Feb 2022 23:54:59 +0100 Original-Received: from localhost ([::1]:57902 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nNjUI-0002oG-8h for ged-emacs-devel@m.gmane-mx.org; Fri, 25 Feb 2022 17:54:58 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49016) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nNj5a-0004mz-Ba for emacs-devel@gnu.org; Fri, 25 Feb 2022 17:29:27 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:64487 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1nNj5Y-0003M3-Gv for emacs-devel@gnu.org; Fri, 25 Feb 2022 17:29:26 -0500 Original-Received: (qmail 44975 invoked by uid 3782); 25 Feb 2022 22:29:02 -0000 Original-Received: from acm.muc.de (p4fe156ec.dip0.t-ipconnect.de [79.225.86.236]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 25 Feb 2022 23:29:02 +0100 Original-Received: (qmail 8049 invoked by uid 1000); 25 Feb 2022 22:29:01 -0000 Content-Disposition: inline In-Reply-To: <831qzyzt5t.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action 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" Xref: news.gmane.io gmane.emacs.devel:286690 Archived-At: Hello, Eli. On Sat, Feb 19, 2022 at 19:02:22 +0200, Eli Zaretskii wrote: > > Date: Sat, 19 Feb 2022 16:42:07 +0000 > > Cc: gregory@heytings.org, monnier@iro.umontreal.ca, mattiase@acm.org, > > larsi@gnus.org, emacs-devel@gnu.org > > From: Alan Mackenzie > > > > I haven't got any useful information out of the exercise, so far. I > > can't help feeling that I'm missing something. Is there anything I ought > > to be doing that I've not yet done? > Maybe you should make EQ real function, with an attribute that would > preclude its inlining. > I have no other ideas. Maybe someone else does. I now have some numbers. I've compared the versions of the master branch just before and just after the merge of scratch/correct-warning-pos with this difference in the new version: (i) A binding of load-read-function was removed (this should be irrelevant). , and this difference in the old version: (i) The macro/function BASE_EQ was copied from the new version and NILP amended to use it. This excludes NILP from contributing to the EQ measurements in the old version, just as it is in the new. In both versions, the inlining was removed from EQ, which was then inserted into xdisp.c as a normal function which invokes the macro lisp_h_EQ. This macro differs between the old and new versions. These two versions were configured the same, without native-compilation, and built. A make check was run to compile (most of) the test-foo.elc files. Then in each the following were run: $ perf record -e cpu-clock make check $ perf report -i perf.data --tui .. The proportions of the profiler samples in EQ were: (old): 0.48% (new): 0.86% .. This is fairly close to the guessed factor of 2 difference. However, it doesn't, by itself, account for the difference in total run time between the two versions. The total number of events counted for these make check runs was (old): 372k (new): 419k .. The breakdown of samples on individual instructions in the old and new versions of EQ is thus: (old): EQ /home/acm/emacs/emacs.git/sub-master-b/src/emacs [Percent: local period] Samples│ │ │ │ Disassembly of section .text: │ │ 0000000000071550 : │ EQ(): │ │ /* STOUGH, 2022-02-19 */ │ bool │ EQ (Lisp_Object x, Lisp_Object y) │ { │ return lisp_h_EQ (x, y); 946 │ cmp %rdi,%rsi 172 │ sete %al │ } 675 │ ← ret ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (new): EQ /home/acm/emacs/emacs.git/sub-master-2/src/emacs [Percent: local period] Samples│ │ │ │ Disassembly of section .text: │ │ 000000000006d150 : │ EQ(): │ no-ops. */ │ │ INLINE EMACS_INT │ (XLI) (Lisp_Object o) │ { │ return lisp_h_XLI (o); 1230 │ mov $0x1,%eax │ │ /* STOUGH, 2022-02-19 */ │ bool │ EQ (Lisp_Object x, Lisp_Object y) │ { │ return lisp_h_EQ (x, y); 311 │ cmp %rsi,%rdi 617 │ ↓ je 76 │ movzbl globals+0xfee,%eax 1340 │ test %al,%al 81 │ ↓ je 76 │ TAGGEDP(): │ Equivalent to XTYPE (a) == TAG, but often faster. */ │ │ INLINE bool │ (TAGGEDP) (Lisp_Object a, enum Lisp_Type tag) │ { │ return lisp_h_TAGGEDP (a, tag); │ lea -0x5(%rdi),%eax │ PSEUDOVECTORP(): │ #define MOST_NEGATIVE_FIXNUM (-1 - MOST_POSITIVE_FIXNUM) │ │ INLINE bool │ PSEUDOVECTORP (Lisp_Object a, int code) │ { │ return lisp_h_PSEUDOVECTORP (a, code); 5 │ test $0x7,%al 9 │ ↓ jne 50 │ movabs $0x400000003f000000,%rdx │ mov -0x5(%rdi),%rcx 1 │ movabs $0x4000000006000000,%rax │ and %rdx,%rcx │ cmp %rax,%rcx │ ↓ jne 50 │ EQ(): │ test $0x7,%sil │ ↓ jne 90 │ cmp %rsi,0x3(%rdi) │ sete %al │ ← ret │ nop │ TAGGEDP(): │ return lisp_h_TAGGEDP (a, tag); │50: lea -0x5(%rsi),%eax │ PSEUDOVECTORP(): │ return lisp_h_PSEUDOVECTORP (a, code); 4 │ test $0x7,%al 5 │ ↓ jne 74 │ movabs $0x400000003f000000,%rax │ and -0x5(%rsi),%rax 1 │ movabs $0x4000000006000000,%rdx │ cmp %rdx,%rax │ ↓ je 80 │74: xor %eax,%eax │ EQ(): │ } 1 │76: ← ret │ nop │ return lisp_h_EQ (x, y); │80: test $0x7,%dil │ ↑ jne 74 │ cmp %rdi,0x3(%rsi) │ sete %al │ ← ret │ xchg %ax,%ax │ TAGGEDP(): │ return lisp_h_TAGGEDP (a, tag); │90: lea -0x5(%rsi),%r8d │ PSEUDOVECTORP(): │ xor %eax,%eax │ return lisp_h_PSEUDOVECTORP (a, code); │ and $0x7,%r8d │ ↑ jne 76 │ and -0x5(%rsi),%rdx │ cmp %rcx,%rdx │ ↑ jne 76 │ EQ(): │ mov 0x3(%rdi),%rax │ cmp %rax,0x3(%rsi) │ sete %al │ ← ret ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; As yet, I don't know quite what to make of these numbers. -- Alan Mackenzie (Nuremberg, Germany).