unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#35321: [PATCH] * src/bytecode.c (exec_byte_code) Unroll Blist3 and Blist4
@ 2019-04-19 14:41 Alex Gramiak
  2019-04-19 15:08 ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Alex Gramiak @ 2019-04-19 14:41 UTC (permalink / raw)
  To: 35321

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

Hopefully someone with experience in the byte compiler can affirm that
this is okay. It passes make check for me (outside of 1 flymake error
that occurs in master as well).


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

From ba211b61d2c9e60935415f57b15511477132bccb Mon Sep 17 00:00:00 2001
From: Alexander Gramiak <agrambot@gmail.com>
Date: Fri, 19 Apr 2019 08:29:39 -0600
Subject: [PATCH] * src/bytecode.c (exec_byte_code) Unroll Blist3 and Blist4

---
 src/bytecode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/bytecode.c b/src/bytecode.c
index 40977799bf..b38c21a464 100644
--- a/src/bytecode.c
+++ b/src/bytecode.c
@@ -884,12 +884,12 @@ exec_byte_code (Lisp_Object bytestr, Lisp_Object vector, Lisp_Object maxdepth,
 
 	CASE (Blist3):
 	  DISCARD (2);
-	  TOP = Flist (3, &TOP);
+	  TOP = list3 (TOP, top[1], top[2]);
 	  NEXT;
 
 	CASE (Blist4):
 	  DISCARD (3);
-	  TOP = Flist (4, &TOP);
+	  TOP = list4 (TOP, top[1], top[2], top[3]);
 	  NEXT;
 
 	CASE (BlistN):
-- 
2.21.0


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* bug#35321: [PATCH] * src/bytecode.c (exec_byte_code) Unroll Blist3 and Blist4
  2019-04-19 14:41 bug#35321: [PATCH] * src/bytecode.c (exec_byte_code) Unroll Blist3 and Blist4 Alex Gramiak
@ 2019-04-19 15:08 ` Eli Zaretskii
  2019-04-19 20:30   ` Alex Gramiak
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2019-04-19 15:08 UTC (permalink / raw)
  To: Alex Gramiak; +Cc: 35321

> From: Alex Gramiak <agrambot@gmail.com>
> Date: Fri, 19 Apr 2019 08:41:43 -0600
> 
> Hopefully someone with experience in the byte compiler can affirm that
> this is okay. It passes make check for me (outside of 1 flymake error
> that occurs in master as well).

Does this produce any tangible performance gains?





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#35321: [PATCH] * src/bytecode.c (exec_byte_code) Unroll Blist3 and Blist4
  2019-04-19 15:08 ` Eli Zaretskii
@ 2019-04-19 20:30   ` Alex Gramiak
  2019-04-19 20:49     ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Alex Gramiak @ 2019-04-19 20:30 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 35321

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex Gramiak <agrambot@gmail.com>
>> Date: Fri, 19 Apr 2019 08:41:43 -0600
>> 
>> Hopefully someone with experience in the byte compiler can affirm that
>> this is okay. It passes make check for me (outside of 1 flymake error
>> that occurs in master as well).
>
> Does this produce any tangible performance gains?

It seems to be within error. I was just in the byte compiler recently
and saw that Blist3/4 don't use list3/4 like Blist2 uses list2. If
you're worried about touching older code for little gain, then I guess
it's safer to leave it alone.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#35321: [PATCH] * src/bytecode.c (exec_byte_code) Unroll Blist3 and Blist4
  2019-04-19 20:30   ` Alex Gramiak
@ 2019-04-19 20:49     ` Eli Zaretskii
  2019-04-19 21:31       ` Alex Gramiak
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2019-04-19 20:49 UTC (permalink / raw)
  To: Alex Gramiak; +Cc: 35321

> From: Alex Gramiak <agrambot@gmail.com>
> Cc: 35321@debbugs.gnu.org
> Date: Fri, 19 Apr 2019 14:30:03 -0600
> 
> > Does this produce any tangible performance gains?
> 
> It seems to be within error. I was just in the byte compiler recently
> and saw that Blist3/4 don't use list3/4 like Blist2 uses list2. If
> you're worried about touching older code for little gain, then I guess
> it's safer to leave it alone.

Is there any reason other than performance to make the change?

Also, are Blist3/4 used frequently enough to justify the change?





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#35321: [PATCH] * src/bytecode.c (exec_byte_code) Unroll Blist3 and Blist4
  2019-04-19 20:49     ` Eli Zaretskii
@ 2019-04-19 21:31       ` Alex Gramiak
  2019-04-20  6:20         ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Alex Gramiak @ 2019-04-19 21:31 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 35321

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex Gramiak <agrambot@gmail.com>
>> Cc: 35321@debbugs.gnu.org
>> Date: Fri, 19 Apr 2019 14:30:03 -0600
>> 
>> > Does this produce any tangible performance gains?
>> 
>> It seems to be within error. I was just in the byte compiler recently
>> and saw that Blist3/4 don't use list3/4 like Blist2 uses list2. If
>> you're worried about touching older code for little gain, then I guess
>> it's safer to leave it alone.
>
> Is there any reason other than performance to make the change?

There's no functional difference, so the only remaining aspects are
readability and similarity with the other BlistX cases. I suppose it
loses on the readability front, and it's not much of an issue to be
dissimilar to Blist2. Perhaps it's best to leave this alone after all.

> Also, are Blist3/4 used frequently enough to justify the change?

They're used any time (list x y z) and (list w x y z) are byte-compiled,
so I imagine they're used quite a bit.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#35321: [PATCH] * src/bytecode.c (exec_byte_code) Unroll Blist3 and Blist4
  2019-04-19 21:31       ` Alex Gramiak
@ 2019-04-20  6:20         ` Eli Zaretskii
  2019-04-20 20:05           ` Stefan Monnier
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2019-04-20  6:20 UTC (permalink / raw)
  To: Alex Gramiak, Stefan Monnier; +Cc: 35321

> From: Alex Gramiak <agrambot@gmail.com>
> Cc: 35321@debbugs.gnu.org
> Date: Fri, 19 Apr 2019 15:31:01 -0600
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Alex Gramiak <agrambot@gmail.com>
> >> Cc: 35321@debbugs.gnu.org
> >> Date: Fri, 19 Apr 2019 14:30:03 -0600
> >> 
> >> > Does this produce any tangible performance gains?
> >> 
> >> It seems to be within error. I was just in the byte compiler recently
> >> and saw that Blist3/4 don't use list3/4 like Blist2 uses list2. If
> >> you're worried about touching older code for little gain, then I guess
> >> it's safer to leave it alone.
> >
> > Is there any reason other than performance to make the change?
> 
> There's no functional difference, so the only remaining aspects are
> readability and similarity with the other BlistX cases. I suppose it
> loses on the readability front, and it's not much of an issue to be
> dissimilar to Blist2. Perhaps it's best to leave this alone after all.
> 
> > Also, are Blist3/4 used frequently enough to justify the change?
> 
> They're used any time (list x y z) and (list w x y z) are byte-compiled,
> so I imagine they're used quite a bit.

OK, thanks.  I'm undecided on this.  Stefan, any comments?





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#35321: [PATCH] * src/bytecode.c (exec_byte_code) Unroll Blist3 and Blist4
  2019-04-20  6:20         ` Eli Zaretskii
@ 2019-04-20 20:05           ` Stefan Monnier
  2019-05-03  8:41             ` Eli Zaretskii
  0 siblings, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2019-04-20 20:05 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 35321, Alex Gramiak

> OK, thanks.  I'm undecided on this.  Stefan, any comments?

I don't see any reason to reject the change.


        Stefan





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#35321: [PATCH] * src/bytecode.c (exec_byte_code) Unroll Blist3 and Blist4
  2019-04-20 20:05           ` Stefan Monnier
@ 2019-05-03  8:41             ` Eli Zaretskii
  2019-06-23 17:36               ` Lars Ingebrigtsen
  0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2019-05-03  8:41 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 35321, agrambot

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Alex Gramiak <agrambot@gmail.com>,  35321@debbugs.gnu.org
> Date: Sat, 20 Apr 2019 16:05:16 -0400
> 
> > OK, thanks.  I'm undecided on this.  Stefan, any comments?
> 
> I don't see any reason to reject the change.

OK, so Alex, please go ahead, and thanks.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#35321: [PATCH] * src/bytecode.c (exec_byte_code) Unroll Blist3 and Blist4
  2019-05-03  8:41             ` Eli Zaretskii
@ 2019-06-23 17:36               ` Lars Ingebrigtsen
  0 siblings, 0 replies; 9+ messages in thread
From: Lars Ingebrigtsen @ 2019-06-23 17:36 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 35321, Stefan Monnier, agrambot

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Alex Gramiak <agrambot@gmail.com>,  35321@debbugs.gnu.org
>> Date: Sat, 20 Apr 2019 16:05:16 -0400
>> 
>> > OK, thanks.  I'm undecided on this.  Stefan, any comments?
>> 
>> I don't see any reason to reject the change.
>
> OK, so Alex, please go ahead, and thanks.

It looks like applying the patch was forgotten, so I've now applied
Alex' patch to master.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2019-06-23 17:36 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-19 14:41 bug#35321: [PATCH] * src/bytecode.c (exec_byte_code) Unroll Blist3 and Blist4 Alex Gramiak
2019-04-19 15:08 ` Eli Zaretskii
2019-04-19 20:30   ` Alex Gramiak
2019-04-19 20:49     ` Eli Zaretskii
2019-04-19 21:31       ` Alex Gramiak
2019-04-20  6:20         ` Eli Zaretskii
2019-04-20 20:05           ` Stefan Monnier
2019-05-03  8:41             ` Eli Zaretskii
2019-06-23 17:36               ` Lars Ingebrigtsen

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