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: Sat, 19 Feb 2022 16:42:07 +0000 Message-ID: References: <83a6f631k3.fsf@gnu.org> <838ruq2z5t.fsf@gnu.org> <83v8xt20db.fsf@gnu.org> <83ee4gyzrh.fsf@gnu.org> <83v8xryh4d.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33638"; 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 Sat Feb 19 17:43:55 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 1nLSpv-0008ZU-IU for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Feb 2022 17:43:55 +0100 Original-Received: from localhost ([::1]:37018 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nLSpu-0006Bz-2p for ged-emacs-devel@m.gmane-mx.org; Sat, 19 Feb 2022 11:43:54 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40388) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nLSok-0005Un-Ej for emacs-devel@gnu.org; Sat, 19 Feb 2022 11:42:42 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:26231 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1nLSoQ-00038B-AV for emacs-devel@gnu.org; Sat, 19 Feb 2022 11:42:41 -0500 Original-Received: (qmail 70105 invoked by uid 3782); 19 Feb 2022 16:42:10 -0000 Original-Received: from acm.muc.de (p4fe159ac.dip0.t-ipconnect.de [79.225.89.172]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 19 Feb 2022 17:42:09 +0100 Original-Received: (qmail 22080 invoked by uid 1000); 19 Feb 2022 16:42:07 -0000 Content-Disposition: inline In-Reply-To: <83v8xryh4d.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=ham 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:286476 Archived-At: Hello, Eli. On Sun, Feb 06, 2022 at 20:39:14 +0200, Eli Zaretskii wrote: > > Date: Sun, 6 Feb 2022 18:09:30 +0000 > > Cc: gregory@heytings.org, monnier@iro.umontreal.ca, mattiase@acm.org, > > larsi@gnus.org, emacs-devel@gnu.org > > From: Alan Mackenzie > > > > > Where are the numbers that show how much slower is the current EQ, for > > > > > the case of EQ and not-EQ objects? > > > > We don't have any such numbers. Is it even possible to measure this? On > > > > earlier processors, we could have just counted up processor cycles used > > > > for each instruction, but not any more. > > > Yes, it's possible: use perf. > > I've installed the user side part of perf on my machine. On reading the > > tutorial (which is very difficult), it seems perf acts like a super > > accurate benchmarking program, which measures program runs. > > Maybe I misunderstand what you meant - but I can't see how perf is able > > to report the cycles, etc., taken by a single execution of an instance of > > EQ. > > What exactly do we want to measure, here? > Perf is capable of showing profiles at a source line granularity. > Since the relation of parts of EQ to equal and non-equal objects is > quite clear, the profile produced by perf can be easily interpreted as > pertaining to either of these two possibilities. By comparing the > profiles with the old and the new definitions of EQ you should be able > to measure the slowdown we are interested in. After building each version with CFLAGS='-O2 -g3' and --with-native-compilation, I've run $ perf record -e cpu-clock make check followed by $ perf report -i perf.data --tui on both old and new EQ versions of Emacs. On the old version, there is no sign of EQ. I searched with `/' at the top level of perf report, and found only other functions with "EQ" in the name in two non-Emacs libraries. On the new version, EQ appears just twice when I type `/' EQ RET. The total CPU usage appears to be around 0.01%. In fact the screen looks like this: Samples: 576K of event 'cpu-clock:u', Event count (approx.): 144023250000 Overhead Comma Shared Object Symbol 0.01% emacs emacs [.] EQ 0.00% hg libpython3.9.so.1.0 [.] _PyUnicode_EQ 0.00% emacs emacs [.] EQ Typing RET on one of the two EQ lines, then RET again, displays percentages taken by the various instructions in that particular expansion of EQ. I think part of the problem is that EQ isn't in any particular place in Emacs. In the C source it occurs over 2,700 times. Is there any way to get perf to amalgamate the different occurrences of EQ? 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? > Btw, unlike what you said up-thread, I don't recommend comparing the > version of Emacs before the merge of the branch with today's > codebase. Instead, I suggest to compile two versions of the same > Emacs codebase, one with the old and simple definition of EQ, the > other with the definition we use now on master. This should make the > comparison easier, since the only difference will be how EQ is > defined. -- Alan Mackenzie (Nuremberg, Germany).