unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Robert Boyer <robertstephenboyer@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 69249@debbugs.gnu.org, rms@gnu.org
Subject: bug#69249: bug in native-compile?
Date: Sun, 18 Feb 2024 17:46:09 -0600	[thread overview]
Message-ID: <CAP9n0TOsyiwrhy12454i4MEnCu0ewoHrsMHj1L-QeYVrHYD0iQ@mail.gmail.com> (raw)
In-Reply-To: <CAP9n0TNP-UK+RopMf07D=P-B-GrRHaGJDonSNtOgSDhZ95NeLA@mail.gmail.com>

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

Robert Boyer <robertstephenboyer@gmail.com>
4:39 PM (1 hour ago)
Reply to all
to Andreas, Eli, 69249, Andrea, Stefan, rms
Look out, here it comes, as Tracy Schwarz says.

The following DISASSEMBLE might tell you what you need to do for
native-compile.

Speaking with the utmost sincerity, I know less about the following than I
do about what Proust called the greatest painting in the world, the View of
Delft by Vermmer.  Check it out.

https://www.mauritshuis.nl/en/our-collection/artworks/92-view-of-delft/

Again, this is in SBCL on my $100 Lenovo Chromebook.

* (disassemble 'foo-with-declare)
; disassembly for FOO-WITH-DECLARE
; Size: 60 bytes. Origin: #x52A4AF19                          ;
FOO-WITH-DECLARE
; 19:       4883EC10         SUB RSP, 16
; 1D:       BA14000000       MOV EDX, 20
; 22:       B904000000       MOV ECX, 4
; 27:       48892C24         MOV [RSP], RBP
; 2B:       488BEC           MOV RBP, RSP
; 2E:       B842BD3550       MOV EAX, #x5035BD42              ; #<FDEFN
EXPT>
; 33:       FFD0             CALL RAX
; 35:       31C0             XOR EAX, EAX
; 37:       31C9             XOR ECX, ECX
; 39:       EB0C             JMP L1
; 3B:       0F1F440000       NOP
; 40: L0:   4801C1           ADD RCX, RAX
; 43:       4883C002         ADD RAX, 2
; 47: L1:   4839D0           CMP RAX, RDX
; 4A:       7EF4             JLE L0
; 4C:       488BD1           MOV RDX, RCX
; 4F:       488BE5           MOV RSP, RBP
; 52:       F8               CLC
; 53:       5D               POP RBP
; 54:       C3               RET
NIL
*


On Sun, Feb 18, 2024 at 5:42 PM Robert Boyer <robertstephenboyer@gmail.com>
wrote:

>  If so, we'd be interested to see your code to try and improve our
> compiler.
>
> I hope this helps.  If not, please let me know.
>
>
>
> Robert Boyer <robertstephenboyer@gmail.com>
> 4:19 PM (1 hour ago)
> Reply to all
> to Andreas, Eli, 69249, Andrea, Stefan, rms
> This message is about how important DECLARE and THE are.  If you do not
> handle DECLARE and THE right, people will laugh at native-compile.
>
> Here is an SBCL transcript.  I am running on a $100 Lenovo Chromebook.
>
> I got SBCL with the command sudo apt-get install sbcl.
>
> * (declaim (optimize (safety 0) (speed 3) (debug 0)))
> NIL
> * (defun foo-with-declare (n)
>   (let ((i 0)
>         (sum 0)
>         (max (expt 10 n)))
>     (declare (fixnum i sum max))
>     (loop (cond ((<= i max)
>                  (setq sum (the fixnum (+ sum i))))
>                 (t (return sum)))
>           (incf i))))
> FOO-WITH-DECLARE
> * (time (foo-with-declare 8))
> Evaluation took:
>   0.125 seconds of real time
>   0.123203 seconds of total run time (0.123193 user, 0.000010 system)
>   98.40% CPU
>   135,905,516 processor cycles
>   0 bytes consed
> 5000000050000000
> * (defun foo-without-declare (n)
>   (let ((i 0)
>         (sum 0)
>         (max (expt 10 n)))
>     (loop (cond ((<= i max)
>                  (setq sum (+ sum i)))
>                 (t (return sum)))
>           (incf i))))
> WARNING: redefining COMMON-LISP-USER::FOO-WITHOUT-DECLARE in DEFUN
> FOO-WITHOUT-DECLARE
> * (time (foo-without-declare 8))
> Evaluation took:
>   1.080 seconds of real time
>   1.072932 seconds of total run time (1.072932 user, 0.000000 system)
>   99.35% CPU
>   1,181,369,303 processor cycles
>   0 bytes consed
> 5000000050000000
>
> People go wow about 8X.  How does native-compile do?
>
> There is a great song by Alabama 'If you gonna play in Texas, you gotta
> have a fiddle in the band'. Check it out!
>
> https://www.youtube.com/watch?v=w6r4E514nJg
>
> Bob
>
>
> Bob
>
>
> On Sun, Feb 18, 2024 at 3:28 PM Andreas Schwab <schwab@linux-m68k.org>
> wrote:
>
>> On Feb 18 2024, Robert Boyer wrote:
>>
>> > Furthermore, such declare forms are necessary for life as we know it
>> > in the free world, so that fixnum arithmetic can be used where
>> > appropriate!
>>
>> If you are programming in Emacs Lisp, you need to follow the rules of
>> Emacs Lisp.
>>
>> --
>> Andreas Schwab, schwab@linux-m68k.org
>> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
>> "And now for something completely different."
>>
>
>
> --
> Anything I seem to state should be taken as a question.  I am at least 77
> and feeble.
> Attachments area
> Preview YouTube video If You're Gonna Play In Texas
> If You're Gonna Play In Texas
> <https://www.youtube.com/watch?v=w6r4E514nJg&authuser=0>
> Reply allReplyForward
> Add reaction
>
> On Sun, Feb 18, 2024 at 5:32 PM Stefan Monnier <monnier@iro.umontreal.ca>
> wrote:
>
>> > ;; However, (native-compile "compile-bug.el") results in the following
>> > error message:
>> >
>> > ;; Compiling file
>> > /mnt/chromeos/GoogleDrive/MyDrive/Linux/working/compile-bug.el at Fri
>> Feb
>> > 16 08:25:19 2024
>> > ;; compile-bug.el:2:45: Warning: Unknown defun property ‘fixnum’ in foo
>> > ;; compile-bug.el:2:45: Warning: Unknown defun property ‘vector’ in foo
>>
>> First thing: these are not error messages!  They're *warnings*!
>>
>> `batch-byte-compile` also gives those warnings, because ELisp does not
>> know those declarations.  The native compiler does support some type
>> annotations, but they do not take this shape.
>>
>> I presume you took those from some other Lisp dialect, but that won't do
>> you much good.  Scheme is not Clojure is not Common Lisp is not ELisp ...
>>
>> BTW, A more recent Emacs would give you an additional warning:
>>
>>     Warning: file has no ‘lexical-binding’ directive on its first line
>>
>> So, I see no bug.  Did the resulting native-compile misbehave in
>> any way?  I presume you're worried about its performance.
>> If so, do you have concrete code where you measured the performance and
>> were disappointed and where you have good reasons to believe that type
>> annotations would make a difference?  If so, we'd be interested to see
>> your code to try and improve our compiler.
>>
>>
>>         Stefan
>>
>>
>
> --
> Anything I seem to state should be taken as a question.  I am at least 77
> and feeble.
>


-- 
Anything I seem to state should be taken as a question.  I am at least 77
and feeble.

[-- Attachment #2: Type: text/html, Size: 30034 bytes --]

  reply	other threads:[~2024-02-18 23:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-18  4:26 bug#69249: bug in native-compile? Robert Boyer
2024-02-18 19:44 ` Eli Zaretskii
2024-02-18 20:14   ` Robert Boyer
2024-02-18 21:28     ` Andreas Schwab
2024-02-18 22:19       ` Robert Boyer
2024-02-18 22:25         ` Robert Boyer
2024-02-18 22:39           ` Robert Boyer
2024-02-19  3:30         ` Eli Zaretskii
2024-02-19  3:58           ` Robert Boyer
2024-02-19  7:48   ` Andrea Corallo
2024-02-19 12:49     ` Eli Zaretskii
2024-02-18 22:45 ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-18 23:32 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-18 23:42   ` Robert Boyer
2024-02-18 23:46     ` Robert Boyer [this message]
2024-02-19 15:13     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]       ` <CAP9n0TOTEZJy8VXeSyMZpT59u0a434_MiwBA0LrwgjH2xc44ww@mail.gmail.com>
2024-02-20  2:51         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-20  3:42           ` Robert Boyer

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=CAP9n0TOsyiwrhy12454i4MEnCu0ewoHrsMHj1L-QeYVrHYD0iQ@mail.gmail.com \
    --to=robertstephenboyer@gmail.com \
    --cc=69249@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=rms@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).