all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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
Date: Sat, 21 Mar 2020 23:39:52 +0000	[thread overview]
Message-ID: <xjfmu89ffav.fsf@sdf.org> (raw)
In-Reply-To: <xjfwo7dh0w5.fsf@sdf.org> (Andrea Corallo's message of "Sat, 21 Mar 2020 21:08:10 +0000")

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

Andrea Corallo <akrl@sdf.org> writes:

> Alan Mackenzie <acm@muc.de> writes:
>
>>
>> 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 :)

At this point the evening has been dedicated to this.  Apparently part
of the issue is that GCC is quite conservative on the inline policy and
because the more complex condition in EQ decide not to inline this (at
least I see this is not done always).  This is true for EQ and some of
his friends defined in lisp.h.  Part of the cost is not the branch
itself but the additional procedure activations.

Pushing a little more into inlining GCC with the raw attached patch I
got it down on the mackenzie-test to 18.17s that is still/just 9% out.
The remaining part is probably a little harder to investigate but I
still suspect more of a 'side reasons' than a fundamental one.

I suggest we try the fine tuning when rebased on 28 if not too hard.

Regards

  Andrea

--
akrl@sdf.org

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tmp.patch --]
[-- Type: text/x-diff, Size: 3857 bytes --]

diff --git a/src/lisp.h b/src/lisp.h
index a22043026a..d0c56d7bbb 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)))                                    \
@@ -1137,38 +1141,38 @@ enum More_Lisp_Bits
 #define MOST_POSITIVE_FIXNUM (EMACS_INT_MAX >> INTTYPEBITS)
 #define MOST_NEGATIVE_FIXNUM (-1 - MOST_POSITIVE_FIXNUM)
 \f
-INLINE bool
+INLINE bool  __attribute__ ((always_inline))
 PSEUDOVECTORP (Lisp_Object a, int code)
 {
   return lisp_h_PSEUDOVECTORP (a, code);
 }
 
-INLINE bool
+INLINE bool  __attribute__ ((always_inline))
 (BARE_SYMBOL_P) (Lisp_Object x)
 {
   return lisp_h_BARE_SYMBOL_P (x);
 }
 
-INLINE bool
+INLINE bool  __attribute__ ((always_inline))
 (SYMBOL_WITH_POS_P) (Lisp_Object x)
 {
   return lisp_h_SYMBOL_WITH_POS_P (x);
 }
 
-INLINE bool
+INLINE bool  __attribute__ ((always_inline))
 (SYMBOLP) (Lisp_Object x)
 {
   return lisp_h_SYMBOLP (x);
 }
 
-INLINE struct Lisp_Symbol_With_Pos *
+INLINE struct Lisp_Symbol_With_Pos *  __attribute__ ((always_inline))
 XSYMBOL_WITH_POS (Lisp_Object a)
 {
     eassert (SYMBOL_WITH_POS_P (a));
     return XUNTAG (a, Lisp_Vectorlike, struct Lisp_Symbol_With_Pos);
 }
 
-INLINE struct Lisp_Symbol * ATTRIBUTE_NO_SANITIZE_UNDEFINED
+INLINE struct Lisp_Symbol *  __attribute__ ((always_inline)) ATTRIBUTE_NO_SANITIZE_UNDEFINED
 (XBARE_SYMBOL) (Lisp_Object a)
 {
 #if USE_LSB_TAG
@@ -1186,7 +1190,7 @@ INLINE struct Lisp_Symbol * ATTRIBUTE_NO_SANITIZE_UNDEFINED
 #endif
 }
 
-INLINE struct Lisp_Symbol * ATTRIBUTE_NO_SANITIZE_UNDEFINED
+INLINE struct Lisp_Symbol *  __attribute__ ((always_inline)) ATTRIBUTE_NO_SANITIZE_UNDEFINED
 (XSYMBOL) (Lisp_Object a)
 {
   return lisp_h_XSYMBOL (a);
@@ -1336,7 +1340,7 @@ INLINE bool
 
 /* Return true if X and Y are the same object, reckoning a symbol with
    position as being the same as the bare symbol.  */
-INLINE bool
+inline bool __attribute__ ((always_inline))
 (EQ) (Lisp_Object x, Lisp_Object y)
 {
   return lisp_h_EQ (x, y);
@@ -2690,7 +2694,7 @@ XOVERLAY (Lisp_Object a)
   return XUNTAG (a, Lisp_Vectorlike, struct Lisp_Overlay);
 }
 
-INLINE Lisp_Object
+INLINE Lisp_Object  __attribute__ ((always_inline))
 SYMBOL_WITH_POS_SYM (Lisp_Object a)
 {
   if (!SYMBOL_WITH_POS_P (a))
@@ -2698,7 +2702,7 @@ SYMBOL_WITH_POS_SYM (Lisp_Object a)
   return XSYMBOL_WITH_POS (a)->sym;
 }
 
-INLINE Lisp_Object
+INLINE Lisp_Object  __attribute__ ((always_inline))
 SYMBOL_WITH_POS_POS (Lisp_Object a)
 {
   if (!SYMBOL_WITH_POS_P (a))

  reply	other threads:[~2020-03-21 23:39 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 [this message]
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

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

  git send-email \
    --in-reply-to=xjfmu89ffav.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 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.