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 [Was: GNU is looking for Google Summer of Code Projects] Date: Sat, 21 Mar 2020 11:22:03 +0000 Message-ID: References: <20200319203449.GA4180@ACM> <20200320191846.GA5255@ACM> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="115862"; 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 12:22:48 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 1jFcDI-000U3e-0r for ged-emacs-devel@m.gmane-mx.org; Sat, 21 Mar 2020 12:22:48 +0100 Original-Received: from localhost ([::1]:35220 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jFcDG-00033d-WF for ged-emacs-devel@m.gmane-mx.org; Sat, 21 Mar 2020 07:22:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59391) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jFcCg-0002UP-VL for emacs-devel@gnu.org; Sat, 21 Mar 2020 07:22:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jFcCf-00046H-Gq for emacs-devel@gnu.org; Sat, 21 Mar 2020 07:22:10 -0400 Original-Received: from mx.sdf.org ([205.166.94.20]:62812) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jFcCf-000440-57; Sat, 21 Mar 2020 07:22:09 -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 02LBM3Qe023882 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 21 Mar 2020 11:22:03 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 02LBM3K7028675; Sat, 21 Mar 2020 11:22:03 GMT In-Reply-To: <20200320191846.GA5255@ACM> (Alan Mackenzie's message of "Fri, 20 Mar 2020 19:18:46 +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:245627 Archived-At: Alan Mackenzie writes: > It's in the branch scratch/accurate-warning-pos. The commit which > converted the unfinished work to a bug fix was: > > commit 2e04ddadab266d245a3bd0f6c19223ea515bdb90 > Author: Alan Mackenzie > Date: Fri Nov 30 14:55:48 2018 +0000 > > Sundry amendments to branch scratch/accurate-warning-pos. > > (except, I think it still outputs two positions for each warning > message: the traditional one, and the new correct one). > I all, I've took a very quick look to the accurate-warning-pos and did some measures. I've measured the bootstrap time and run elisp-benchmarks (dhrystone take out cause broken on both branches) comparing accurate-warning-pos against the last in-tree commit it's based on. Here what I see on my dev machine: * b071398ba3 @ scratch/accurate-warning-pos ** bootstrap real 2m31.076s user 15m8.049s sys 0m38.087s ** elisp-benckmarks | test | non-gc avg (s) | gc avg (s) | gcs avg | tot avg (s) | tot avg err (s) | |----------------+----------------+------------+---------+-------------+-----------------| | bubble-no-cons | 11.53 | 0.04 | 4 | 11.57 | 0.01 | | bubble | 4.74 | 3.81 | 484 | 8.55 | 0.00 | | fibn-rec | 6.35 | 0.00 | 0 | 6.35 | 0.00 | | fibn-tc | 5.59 | 0.00 | 0 | 5.59 | 0.02 | | fibn | 11.90 | 0.00 | 0 | 11.90 | 0.01 | | inclist | 17.86 | 0.01 | 1 | 17.87 | 0.01 | | listlen-tc | 6.48 | 0.00 | 0 | 6.48 | 0.01 | | nbody | 3.58 | 6.70 | 839 | 10.28 | 0.01 | | pidigits | 5.60 | 5.68 | 457 | 11.28 | 0.03 | |----------------+----------------+------------+---------+-------------+-----------------| | total | 73.62 | 16.24 | 1785 | 89.86 | 0.04 | * b619777dd6 (baseline) ** bootstrap real 2m20.762s user 13m35.418s sys 0m37.349s ** elisp-benckmarks | test | non-gc avg (s) | gc avg (s) | gcs avg | tot avg (s) | tot avg err (s) | |----------------+----------------+------------+---------+-------------+-----------------| | bubble-no-cons | 11.43 | 0.04 | 4 | 11.47 | 0.00 | | bubble | 4.67 | 3.58 | 487 | 8.25 | 0.01 | | fibn-rec | 6.21 | 0.00 | 0 | 6.21 | 0.00 | | fibn-tc | 5.68 | 0.00 | 0 | 5.68 | 0.00 | | fibn | 11.47 | 0.00 | 0 | 11.47 | 0.00 | | inclist | 17.37 | 0.01 | 1 | 17.38 | 0.00 | | listlen-tc | 6.46 | 0.00 | 0 | 6.46 | 0.00 | | nbody | 3.36 | 6.24 | 839 | 9.60 | 0.01 | | pidigits | 5.66 | 5.53 | 457 | 11.19 | 0.03 | |----------------+----------------+------------+---------+-------------+-----------------| | total | 72.32 | 15.39 | 1788 | 87.71 | 0.03 | The outcome as I see it is that total bootstrap time gets bigger 1.1x while normal runtime appears not affected. For my quick understanding of how it works this is expected. The additional branch and compare against symbols_with_pos_enabled in `eq' is a kind of branch that is very easily predictable by any modern CPU, therefore when the feature is off (not compiling) it becomes transparent (I'd see a compiler branch hit there too). elisp-benchmarks are not completely rapresentative for now but again... better than nothing. Am I missing something else here or we are trading out the exact solution for like ~15% off the byte compile-time? I think this feature would be a big step forward for our toolchain opening many possibilities. I suspect fat conses will requires more modifications across the whole compilation pipeline (including macros?) bringing a less accurate result and still they have to prove the smaller overhead. At this point I start suspecting I'm missing something very big here, am I? Anyway thanks Alan for this. Andrea -- akrl@sdf.org