From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: Correct line/column numbers in byte compiler messages Date: Sat, 21 Mar 2020 21:08:10 +0000 Message-ID: References: <20200319203449.GA4180@ACM> <20200320191846.GA5255@ACM> <20200321153041.GA7805@ACM> <20200321201954.GB7805@ACM> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="33100"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: Rocky Bernstein , Stefan Monnier , emacs-devel To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Mar 21 22:08:59 2020 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 1jFlMX-0008Tr-6c for ged-emacs-devel@m.gmane-mx.org; Sat, 21 Mar 2020 22:08:57 +0100 Original-Received: from localhost ([::1]:40916 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jFlMU-0000Rn-SD for ged-emacs-devel@m.gmane-mx.org; Sat, 21 Mar 2020 17:08:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52667) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jFlLs-0008Qm-MJ for emacs-devel@gnu.org; Sat, 21 Mar 2020 17:08:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jFlLo-0004TO-Mv for emacs-devel@gnu.org; Sat, 21 Mar 2020 17:08:16 -0400 Original-Received: from mx.sdf.org ([205.166.94.20]:55623) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jFlLo-0004Sw-Ch; Sat, 21 Mar 2020 17:08:12 -0400 Original-Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 02LL8Atj003133 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 21 Mar 2020 21:08:10 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 02LL8AY9014475; Sat, 21 Mar 2020 21:08:10 GMT In-Reply-To: <20200321201954.GB7805@ACM> (Alan Mackenzie's message of "Sat, 21 Mar 2020 20:19:54 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 205.166.94.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:245646 Archived-At: --=-=-= Content-Type: text/plain Alan Mackenzie writes: > On my Ryzen, I'm seeing a 50% penalty. :-( (Admittedly that's > comparing the year old branch to current master. I suppose I should > build the correct comparable revision and try again.) This suggests > that the branch prediction logic isn't present (or isn't active) on the > Ryzen. This is very strange. You cerntaly have to compare branches from the same epoch. I pretty sure in the last year Paul pushed changes to the inline policy with some measureble effect on performance. >> Interestingly with the __builtin_expect trick applied exec time gets >> back to 50.65s. > > How do you do this? I couldn't make much sense of the documentation of > __builtin_expect. :-( I attach the very simple patch I tried. Basically the compiler has an euristic branch predictor (in GCC predict.c) that is used to order the final basic block output. The wanted outcome is to have the most likely execution line as sequential, this on modern CPUs to maximize the front-end bandwidth. "__builtin_expect" is just a strong hint to this predictor. >> We could probably find a benchmark that better highlights the difference >> (this is potentially dominated by cache misses while pointer chasing the >> list) but is it worth? > > Could I ask you to do the following timing. > > Evaluate the following (e.g. in *scratch*): > > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > (defmacro time-it (&rest forms) > "Time the running of a sequence of forms using `float-time'. > Call like this: \"M-: (time-it (foo ...) (bar ...) ...)\"." > `(let ((start (float-time))) > ,@forms > (- (float-time) start))) > > (defun time-scroll (&optional arg) > (interactive "P") > (message "%s" > (time-it > (condition-case nil > (while t > (if arg (scroll-down) (scroll-up)) > (sit-for 0)) > (error nil))))) > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; > > , visit .../emacs/src/xdisp.c, and do M-: (time-scroll). This scrolls > through the buffer and prints a timing in the minibuffer. (N.B. to run > this again, type something at BOB and undo it, thus marking the > fontification as stale.) > > I'm seeing 19.4s vs. 22.2s, which is around 15% difference. :-( I get 19.30 sec against 16.65 that is 15% difference here too. This is extremely interesting and would be worth profiling. I bet on the GC for this! (Note I'm notoriously wrong when speculating on benchmarks :) Regards Andrea -- akrl@sdf.org --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=comp-hint.patch diff --git a/src/lisp.h b/src/lisp.h index a22043026a..6e3cca1bbc 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -394,8 +394,12 @@ typedef EMACS_INT Lisp_Word; /* #define lisp_h_EQ(x, y) (XLI (x) == XLI (y)) */ /* verify (NIL_IS_ZERO) */ + +#define SYMBOLS_WITH_POS_ENABLED \ + __builtin_expect(symbols_with_pos_enabled, 0) + #define lisp_h_EQ(x, y) ((XLI ((x)) == XLI ((y))) \ - || (symbols_with_pos_enabled \ + || (SYMBOLS_WITH_POS_ENABLED \ && (SYMBOL_WITH_POS_P ((x)) \ ? BARE_SYMBOL_P ((y)) \ ? (XSYMBOL_WITH_POS((x)))->sym == (y) \ @@ -424,7 +428,7 @@ typedef EMACS_INT Lisp_Word; #define lisp_h_BARE_SYMBOL_P(x) TAGGEDP ((x), Lisp_Symbol) /* verify (NIL_IS_ZERO) */ #define lisp_h_SYMBOLP(x) ((BARE_SYMBOL_P ((x)) || \ - (symbols_with_pos_enabled && (SYMBOL_WITH_POS_P ((x)))))) + (SYMBOLS_WITH_POS_ENABLED && (SYMBOL_WITH_POS_P ((x)))))) #define lisp_h_TAGGEDP(a, tag) \ (! (((unsigned) (XLI (a) >> (USE_LSB_TAG ? 0 : VALBITS)) \ - (unsigned) (tag)) \ @@ -463,7 +467,7 @@ typedef EMACS_INT Lisp_Word; /* verify (NIL_IS_ZERO) */ # define lisp_h_XSYMBOL(a) \ (eassert (SYMBOLP ((a))), \ - (!symbols_with_pos_enabled \ + (!SYMBOLS_WITH_POS_ENABLED \ ? (XBARE_SYMBOL ((a))) \ : (BARE_SYMBOL_P ((a))) \ ? (XBARE_SYMBOL ((a))) \ --=-=-=--