all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Andrea Corallo <akrl@sdf.org>
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
Date: Sun, 22 Mar 2020 11:26:19 +0000	[thread overview]
Message-ID: <20200322112619.GA32470@ACM> (raw)
In-Reply-To: <20200321201954.GB7805@ACM>

Hello, Andrea.

On Sat, Mar 21, 2020 at 20:19:54 +0000, Alan Mackenzie wrote:
> On Sat, Mar 21, 2020 at 18:37:13 +0000, Andrea Corallo wrote:
> > Have to apologize this is probably the quarantine effect ....

> As of today, we're under quarantine, too.  :-(

> > .... but I couldn't resist testing this:

> > #+BEGIN_SRC lisp
> > ;; -*- lexical-binding: t; -*-
> > (require 'cl-lib)
> > (defvar elb-list (cl-loop for i from 0 to 1500000
> >                           if (cl-oddp i)
> >                           collect 'a
> >                           else
> >                           collect 'b))

> > (defun elb-eq ()
> >   (let ((n 0))
> >     (dolist (l elb-list n)
> >       (when (eq 'b l)
> >         (cl-incf n)))))

> > (defun elb-eq-entry ()
> >   (dotimes (_ 1000)
> >     (elb-eq)))
> > #+END_SRC

> > Results:

> > b619777dd6 (baseline) 50.09s
> > accurate-warning-pos  51.28s

> > This is about 2% perf penalty.

> 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.

OK, I've done just that (with revision
b619777dd67e271d639c6fb1d031650af8fd79e6 from 2019-03-30) and I now see
what you see:
b619777:                      76.067s
scratch/accurate-warning-pos: 77.656s.
master:                       52.423s

So, clearly, optimisations to Emacs in the last year have borne fruit.
Maybe that optimisaton would be useful in s/a-w-p.

> > 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've read your patch in your other mail, and I will apply it and try it
out.

[ .... ]

> > Regards

> >   Andrea

> > --
> > akrl@sdf.org

-- 
Alan Mackenzie (Nuremberg, Germany).



  parent reply	other threads:[~2020-03-22 11:26 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
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 [this message]
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200322112619.GA32470@ACM \
    --to=acm@muc.de \
    --cc=akrl@sdf.org \
    --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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.