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))
next prev parent 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
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=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 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).