From: Andrea Corallo <akrl@sdf.org>
To: Alan Mackenzie <acm@muc.de>
Cc: Rocky Bernstein <rocky@gnu.org>,
Stefan Monnier <monnier@iro.umontreal.ca>,
emacs-devel <emacs-devel@gnu.org>
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 [thread overview]
Message-ID: <xjfy2rukl5w.fsf@sdf.org> (raw)
In-Reply-To: <20200320191846.GA5255@ACM> (Alan Mackenzie's message of "Fri, 20 Mar 2020 19:18:46 +0000")
Alan Mackenzie <acm@muc.de> 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 <acm@muc.de>
> 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
next prev parent reply other threads:[~2020-03-21 11:22 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-19 15:10 GNU is looking for Google Summer of Code Projects Rocky Bernstein
2020-03-19 17:35 ` Stefan Monnier
2020-03-19 17:56 ` Andrea Corallo
2020-03-19 18:05 ` Andrea Corallo
2020-03-19 18:19 ` Rocky Bernstein
2020-03-19 21:26 ` Stefan Monnier
2020-03-19 21:45 ` Andrea Corallo
2020-03-19 23:07 ` Rocky Bernstein
2020-03-19 20:34 ` Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects] Alan Mackenzie
2020-03-19 20:43 ` Andrea Corallo
2020-03-20 19:18 ` Alan Mackenzie
2020-03-21 11:22 ` Andrea Corallo [this message]
2020-03-21 15:30 ` Correct line/column numbers in byte compiler messages Alan Mackenzie
2020-03-21 16:28 ` Andrea Corallo
2020-03-21 18:37 ` Andrea Corallo
2020-03-21 20:19 ` Alan Mackenzie
2020-03-21 21:08 ` Andrea Corallo
2020-03-21 23:39 ` Andrea Corallo
2020-03-22 11:26 ` Alan Mackenzie
2020-03-19 20:56 ` Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects] Rocky Bernstein
2020-03-19 22:05 ` Stefan Monnier
2020-03-20 19:25 ` Alan Mackenzie
2020-03-19 21:41 ` Stefan Monnier
2020-03-19 22:09 ` Stefan Monnier
2020-03-20 20:10 ` Alan Mackenzie
2020-03-20 21:23 ` Rocky Bernstein
2020-03-20 21:27 ` Clément Pit-Claudel
2020-03-20 23:46 ` Stefan Monnier
2020-03-20 21:30 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xjfy2rukl5w.fsf@sdf.org \
--to=akrl@sdf.org \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=rocky@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).