stats say SBCL is 78 875 % faster than natively compiled Elisp

stats say SBCL is 78 875 % faster than natively compiled Elisp

[Emanuel Berg]

;;; -*- lexical-binding: t -*-
;;
;; this file:
;;   https://dataswamp.org/~incal/emacs-init/fib.el
;;
;; the CL:
;;   https://dataswamp.org/~incal/cl/fib.cl
;;
;; code from:
;;   elisp-benchmarks-1.14
;;
;; commands: [results]
;;   $ emacs -Q -batch -l fib.el                    [8.660 s]
;;   $ emacs -Q -batch -l fib.elc                   [3.386 s]
;;   $ emacs -Q -batch -l fib-54a44480-bad305eb.eln [3.159 s]
;;   $ sbcl -l fib.cl                               [0.004 s]
;;
;; (stats)
;;   plain  -> byte:     +156%
;;   plain  -> native:   +174%
;;   plain  -> sbcl:  +216400%
;;
;;   byte   -> native:     +7%
;;   byte   -> sbcl:   +84550%
;;
;;   native -> sbcl:   +78875%

(require 'cl-lib)

(defun compare-table (l)
  (cl-loop for (ni ti) in l
           with first = t
        do (setq first t)
           (cl-loop for (nj tj) in l
                 do (when first
                      (insert "\n")
                      (setq first nil))
                    (unless (string= ni nj)
                      (let ((imp (* (- (/ ti tj) 1.0) 100)))
                        (when (< 0 imp)
                          (insert
                            (format ";; %s -> %s: %+.0f%%\n" ni nj imp) )))))))

(defun stats ()
  (let ((p '("plain"  8.660))
        (b '("byte"   3.386))
        (n '("native" 3.159))
        (s '("sbcl"   0.004)) )
    (compare-table (list p b n s)) ))

(defun fib (reps num)
  (let ((z 0))
    (dotimes (_ reps)
      (let ((p1 1)
            (p2 1))
        (dotimes (_ (- num 2))
          (setf z (+ p1 p2)
                p2 p1
                p1 z))))
    z))

(let ((beg (float-time)))
  (fib 10000 1000)
  (message "%.3f s" (- (float-time) beg)) )

;; (shell-command "emacs -Q -batch -l \"~/.emacs.d/emacs-init/fib.el\"")
;; (shell-command "emacs -Q -batch -l \"~/.emacs.d/emacs-init/fib.elc\"")
;; (shell-command "emacs -Q -batch -l \"~/.emacs.d/eln-cache/30.0.50-3b889b4a/fib-54a44480-8bbda87b.eln\"")

(provide 'fib)

-- 
underground experts united
https://dataswamp.org/~incal

Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Chen Zhaoyang]

Emanuel Berg <incal@dataswamp.org> writes:

> (defun fib (reps num)
>   (let ((z 0))
>     (dotimes (_ reps)
>       (let ((p1 1)
>             (p2 1))
>         (dotimes (_ (- num 2))
>           (setf z (+ p1 p2)
>                 p2 p1
>                 p1 z))))
>     z))

Maybe try out (named-let)? It should be fun to rewrite it with tail
calls.

CZY

Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-02-15 02:52]:
> ;;
> ;; commands: [results]
> ;;   $ emacs -Q -batch -l fib.el                    [8.660 s]
> ;;   $ emacs -Q -batch -l fib.elc                   [3.386 s]
> ;;   $ emacs -Q -batch -l fib-54a44480-bad305eb.eln [3.159 s]
> ;;   $ sbcl -l fib.cl                               [0.004 s]

Whatever those stats say, SBCL does not have tabulated-list-mode and
integrated editor in the programming environment (or is it opposite, I
forgot?).

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Emanuel Berg]

Chen Zhaoyang wrote:

>> (defun fib (reps num)
>>   (let ((z 0))
>>     (dotimes (_ reps)
>>       (let ((p1 1)
>>             (p2 1))
>>         (dotimes (_ (- num 2))
>>           (setf z (+ p1 p2)
>>                 p2 p1
>>                 p1 z))))
>>     z))
>
> Maybe try out (named-let)? It should be fun to rewrite it
> with tail calls.

Do it in SBCL as well.

-- 
underground experts united
https://dataswamp.org/~incal

full native compile (was: Re: stats say SBCL is 78 875 % faster than natively compiled Elisp)

[Emanuel Berg]

> ;; byte > native: +7%

Another thing I discovered doing this, not all my Elisp is
natively compiled!

It seems .el files that are just loaded, i.e.
with `load-file', are not natively compiled and cached, for
this to happen one has to use `require' from a file that is
itself natively compiled.

But then, uhm, how dow it all start?

As the experiment above show, the increase in speed compared
to byte compilation isn't huge, but it's still
substantial (7%). I'll take it!

-- 
underground experts united
https://dataswamp.org/~incal

Re: full native compile (was: Re: stats say SBCL is 78 875 % faster than natively compiled Elisp)

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Wed, 15 Feb 2023 13:36:20 +0100
> 
> It seems .el files that are just loaded, i.e.
> with `load-file', are not natively compiled and cached

Yes, and that's a feature.  Otherwise, you wouldn't have any way of
telling Emacs to load a .el file and NOT compile it.

Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Emanuel Berg]

Jean Louis wrote:

>> ;; commands: [results]
>> ;;   $ emacs -Q -batch -l fib.el                    [8.660 s]
>> ;;   $ emacs -Q -batch -l fib.elc                   [3.386 s]
>> ;;   $ emacs -Q -batch -l fib-54a44480-bad305eb.eln [3.159 s]
>> ;;   $ sbcl -l fib.cl                               [0.004 s]
>
> Whatever those stats say

They say CL (with SBCL) is fast; and that natively compiled
Elisp is a good step from byte-compiled Elisp, and a huge leap
from not compiling it at all! However, compared to CL/SBCL our
beloved Elisp/Emacs is still just a turtle on steroids ...

> SBCL does not have tabulated-list-mode and integrated editor
> in the programming environment

Oh, we have Emacs for that! Check this out, including
instructions how to install a bunch of stuff ...

It's SLIME ... as you know well! You are just goofing
around. That's okay.

But while I got it to work, the level of integration is still
below what we have with Elisp. So I thought, with the native
compile step, we could maybe ... but no. Need speed? Use CL.
Simple as that!

;;; -*- lexical-binding: t -*-
;;
;; this file:
;;   https://dataswamp.org/~incal/emacs-init/ide/slime-incal.el
;;
;; install quicklisp and cl-sdl2:
;;   $ sudo apt-get --install-suggests install \*sbcl\* libsdl2-\*
;;   $ mkdir -p ~/common-lisp
;;   $ cd ~/common-lisp
;;   $ wget 'https://beta.quicklisp.org/quicklisp.lisp'
;;
;;   $ sbcl --load quicklisp.lisp
;;   * (quicklisp-quickstart:install)
;;   * (ql:add-to-init-file)
;;   * (quit)
;;
;;   CL-USER> (load "~/quicklisp/setup.lisp")
;;   CL-USER> (ql:quickload "quicklisp-slime-helper")
;;   CL-USER> (ql:update-dist "quicklisp")
;;   CL-USER> (ql:update-client)
;;
;;   CL-USER> (ql:quickload "sdl2")
;;   CL-USER> (ql:quickload :sdl2/examples)
;;   CL-USER> (sdl2-examples:basic-test)
;;
;;   $ sbcl # boot faster, redo this on update to SLIME or SBCL
;;   * (load "~/quicklisp/dists/quicklisp/software/slime-v2.26.1/swank-loader.lisp")
;;   * (swank-loader:dump-image "sbcl.core-with-swank")
;;   * (quit)
;;   then set `slime-lisp-implementations' as below

(require 'slime)
(require 'slime-autoloads)
(require 'slime-banner)
(require 'slime-repl)
(require 'super)

(load (expand-file-name "~/quicklisp/slime-helper.el"))

(setq inferior-lisp-program "/bin/sbcl")

(setq slime-lisp-implementations
      '((sbcl ("sbcl" "--core" "/home/incal/common-lisp/sbcl.core-with-swank")
              :init (lambda (port-file _)
                      (format "(swank:start-server %S)\n" port-file) ))))

(setq slime-startup-animation      nil)
(setq slime-words-of-encouragement nil)

;; sldb

(defun sldb-mode-hook-f ()
  (disable-super-global-keys sldb-mode-map) )
(add-hook 'sldb-mode-hook #'sldb-mode-hook-f)

;; slime

(defun slime-mode-set-keys ()
  (let ((the-map slime-mode-indirect-map))
    (disable-super-global-keys the-map)
    (define-key the-map "\C-hf" #'slime-describe-function)
    (define-key the-map "\M-9"  #'slime-eval-last-expression)
    (define-key the-map "\M-n"  #'slime-eval-buffer) ))

(defun slime-mode-hook-f ()
  (abbrev-mode)
  (slime-mode-set-keys) )
(add-hook 'slime-mode-hook #'slime-mode-hook-f)

;; slime repl

(defun slime-repl-mode-set-keys ()
  (let ((the-map slime-repl-mode-map))
    (disable-super-global-keys the-map)
    (define-key the-map "\C-\M-n" #'slime-repl-next-input)
    (define-key the-map "\C-\M-p" #'slime-repl-previous-input) ))

(defun slime-repl-mode-hook-f ()
  (slime-repl-mode-set-keys) )
(add-hook 'slime-repl-mode-hook #'slime-repl-mode-hook-f)

;; (find-file "~/common-lisp/general-base/gb.lisp")
;; (find-file "~/quicklisp/dists/quicklisp/software/cl-sdl2-20201220-git/examples/basic.lisp")

-- 
underground experts united
https://dataswamp.org/~incal

Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-02-16 22:47]:
> They say CL (with SBCL) is fast; and that natively compiled
> Elisp is a good step from byte-compiled Elisp, and a huge leap
> from not compiling it at all! However, compared to CL/SBCL our
> beloved Elisp/Emacs is still just a turtle on steroids ...

Emacs Lisp is not designed for mission critical applications such as
controlling rockets in the orbit. But wait, let me see:

M-x mission-control

Ah, it's there. 

Speed does not matter for purposes I need, like sales, handling
people, communicating with people.

It matters for processing of e-mails, I have already re-wrote my
program that processes mailings to thousands of people from Perl to
Common Lisp to Emacs Lisp. I prefer it in Emacs Lisp as I can
integrate it way easier with everything else. That is one thing that I
may consider maybe it could be faster, because it blocks the computer,
raises some issues, like heating.

> > SBCL does not have tabulated-list-mode and integrated editor
> > in the programming environment
> 
> Oh, we have Emacs for that! Check this out, including
> instructions how to install a bunch of stuff ...
> 
> It's SLIME ... as you know well! You are just goofing
> around. That's okay.

Is SLIME related to tabulated-list-mode?

Anyway, when I program Common Lisp, I just plain built-in lisp-mode
and it works well.

> But while I got it to work, the level of integration is still
> below what we have with Elisp. So I thought, with the native
> compile step, we could maybe ... but no. Need speed? Use CL.

I used it, I am not satisfied with it due to lack of integration.

To generate "list of things" in Common Lisp is simply difficult, it
needs some GUI and much work. Emacs has interface ready. The text
properties are great. They serve like switches for a key to provide
different functionality. I simply don't have those feautures in Common
Lisp.

There is no ready spreadsheet type of a GUI for Common Lisp where I
can make key bindings for each screen different in as simple way as
how it is in Emacs.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Emanuel Berg]

Jean Louis wrote:

>> However, compared to CL/SBCL our beloved Elisp/Emacs is
>> still just a turtle on steroids ...
>
> Emacs Lisp is not designed for mission critical applications
> such as controlling rockets in the orbit.

I don't think that's the answer - Elisp and CL should be very
close compared as two languages even in the Lisp family, so
the difference in speed should be in the compiling part of it,
as those digits exemplify.

Again, see:

  https://dataswamp.org/~incal/emacs-init/fib.el

;; commands: [results]
;;   $ emacs -Q -batch -l fib.el                    [8.660 s]
;;   $ emacs -Q -batch -l fib.elc                   [3.386 s]
;;   $ emacs -Q -batch -l fib-54a44480-bad305eb.eln [3.159 s]
;;   $ sbcl -l fib.cl                               [0.004 s]
;;
;;   plain  -> byte:     +156%
;;   plain  -> native:   +174%
;;   plain  -> sbcl:  +216400%
;;
;;   byte   -> native:     +7%
;;   byte   -> sbcl:   +84550%
;;
;;   native -> sbcl:   +78875%

So my questions are still:

- Why is our native-compile/Elisp so much slower than their
  SBCL/CL?

- Why is our native-compile just 7% faster than our
  byte-compile? I is still based on the byte-model, just now
  adopted for native hardware?

- But 7% is still a good step forward, so:

(1) Is all Elisp shipped with Emacs natively compiled? [1]

(2) How do I compile all my own Elisp, optimally straight from
    a/the Makefile or still better, implicit/automated
    when/from byte-compiling? [2]

> Speed does not matter for purposes I need, like sales,
> handling people, communicating with people.

Speed always matters in computing.

>> But while I got it to work, the level of integration is
>> still below what we have with Elisp. So I thought, with the
>> native compile step, we could maybe ... but no. Need speed?
>> Use CL.
>
> I used it, I am not satisfied with it due to lack
> of integration.

I think SLIME was intended in part to bridge that gap, and to
some extent I think it succeeded, actually, given the
increased complexity one can argue it succeeded quite well,
but as for how one perceives it after being used to Elisp -
then no, it doesn't feel like that ...

[1] Installed like this:
      https://dataswamp.org/~incal/conf/.zsh/install-emacs

[2} For example:
      https://dataswamp.org/~incal/emacs-init/Makefile

-- 
underground experts united
https://dataswamp.org/~incal

Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Emanuel Berg]

> - Why is our native-compile just 7% faster than our
>   byte-compile? I is still based on the byte-model, just now
>   adopted for native hardware?

*Is it

> Is all Elisp shipped with Emacs natively compiled?

Here you understand what I mean, but it should say: will
it be?

No code shipped with Emacs is natively compiled, as that
happens on the native computer.

But it happens when Emacs is run and when the Elisp is
`required' from another Elisp file that is itself already
natively compiled, so if the Elisp is just loaded with
`load-file', it won't happen.

How can I natively compile _all_ Elisp, my own from the
Makefile when byte-compiling, and all other Elisp just once
and for all since I don't change that? (By all means, the
after change-thing don't have to be disabled or anything as
those method are not contradictory, on the ... contrary.)

-- 
underground experts united
https://dataswamp.org/~incal

Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Sat, 18 Feb 2023 21:15:00 +0100
> 
> How can I natively compile _all_ Elisp, my own from the
> Makefile when byte-compiling, and all other Elisp just once
> and for all since I don't change that? (By all means, the
> after change-thing don't have to be disabled or anything as
> those method are not contradictory, on the ... contrary.)

You could look at how this is done when Emacs is built from the
release tarball, and do something similar.

But if you think you can do that only once, you are mistaken:
basically, each time you want your Lisp to work with a new version of
Emacs, you need to recompile your Lisp into *.eln files anew.

Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Emanuel Berg]

Eli Zaretskii wrote:

>> How can I natively compile _all_ Elisp, my own from the
>> Makefile when byte-compiling, and all other Elisp just once
>> and for all since I don't change that? (By all means, the
>> after change-thing don't have to be disabled or anything as
>> those method are not contradictory, on the ... contrary.)
>
> You could look at how this is done when Emacs is built from the
> release tarball, and do something similar.

Good idea.

> But if you think you can do that only once, you are
> mistaken: basically, each time you want your Lisp to work
> with a new version of Emacs, you need to recompile your Lisp
> into *.eln files anew.

... and when I get a new computer as well?

-- 
underground experts united
https://dataswamp.org/~incal

Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-02-18 23:23]:
> > Speed does not matter for purposes I need, like sales,
> > handling people, communicating with people.
> 
> Speed always matters in computing.

You have generalized my personal specific answer. 

To find out if speed matters you would need to ask people to
understand their personal needs. General statements may not be always
practically useful. What really matters is the use for people.

I have been programming in Perl, it gave me useful life period. Then
there was HTML rendering in Perl. Personally I had to consider whole
system that was of use for me as human, the Perl programming language,
an browser that was displaying the rendered HTML as program
application GUI. I have tried using it from CLI by using Common
Lisp. I cannot say that Common Lisp os so "Common". Every
implementation is different. For simple programming functions I have
to change to this or that implementation. And integration of packages
is not smooth as one expects it. Let me say it is worse, not as
reliable, than Perl package (CPAN). Is speed the only factor? I don't
think so. Then I tried it out with Emacs Lisp, and because there are
many features already built-in it spares me time of programming. 

Emacs offers GUI already, hyperlinks (buttons). Imagine only those two
features for example. Then simple function can list those files
hyperlinked and let me as user click to see the generated PDF with the
invoice. Does it matter that some milliseconds pass? No.

Another example is searching for particular contact in the database,
sometimes it would take longer time, like 1-2 seconds. But I know how
to speed it up. Would it be faster with Common Lisp? Probably, but
personally does not matter, as the features in Emacs are taken for
granted and spare my time to program. In the same way the PostgreSQL
database spare my time to program.

And finally, there is no HTML rendering, no browser, and it all comes
faster than with the HTML GUI. 

Could I do it with Common Lisp faster? Probably yes, but in the end I
would spend more time programming it, as Common Lisp does not have
integrated features like Emacs. 

If you do know how to quickly create Common Lisp GUI with spreadsheet,
that I can change keybindings on every different listing, with
multiple instances running in the same time (multiple buffers) then
let me know. I would like to use it, but I did not find solution.

In Emacs one can detect what other buffers are displayed, move object
from one buffer's place to other buffer's place. 

tabulated-list-mode gives me that solution built-in, I can list
database objects and do something on them. It is most similar to
spreadshet widget. As much as I look into GUIs for Common Lisp, I
cannot easily find solution. I would need to program too much. At
least that is my impression.

Which solution for the above description can be replaced by Common Lisp?
https://common-lisp.net/libraries

I would like to know, as I want to try it out.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Sat, 18 Feb 2023 21:47:16 +0100
> 
> > But if you think you can do that only once, you are
> > mistaken: basically, each time you want your Lisp to work
> > with a new version of Emacs, you need to recompile your Lisp
> > into *.eln files anew.
> 
> ... and when I get a new computer as well?

No, not if the new computer runs the same OS and is capable of running
the same Emacs binary you built on the old one.  Just make sure you
don't customize native-comp-driver-options and/or
native-comp-driver-options to include compiler switches that are valid
only for certain CPU architectures.  (Customizing those is discouraged
anyway.)

Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Madhu]

pardon the blog -- to test the validity of the claims in this thread I
was trying to run

```
(time (fib 2000 500))
(time (slynk::eval-in-emacs '(fib 5000 500)))
```
from within some lisp to compare the elapsed time.

However when I tried to "native" compile Emanuel Berg's fib function in
a file fib.el
```
;; -*- lexical-binding: t -*-
(defun fib (reps num)
  (let ((z 0))
    (dotimes (_ reps)
      (let ((p1 1)
            (p2 1))
        (dotimes (_ (- num 2))
          (setf z (+ p1 p2)
                p2 p1
                p1 z))))
    z))
```
with  (byte-compile-file "fib.el" t)
I got a fib.elc which was loaded, but the file was not natively
compiled.

(dissassemble 'fib) only shows the byte code.

I was under the impression that this should have automatically produced
an eln file with default native-* variables which i've reviewed.

I was able to produce the eln file with an explicit call to
```
(load (native-compile "fib.el"))
or M-x emacs-lisp-native-compile-and-load
```
and load it and dissassemble it

Is my understanding of the documentation - that native compilation is an
automatic side effect of byte compiling, wrong?

Last tried on the `master' branch with sources from around 2023-02-15

Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Eli Zaretskii]

> From: Madhu <enometh@meer.net>
> Date: Tue, 21 Feb 2023 12:34:21 +0530
> 
> Is my understanding of the documentation - that native compilation is an
> automatic side effect of byte compiling, wrong?

Yes, it's wrong.  Native compilation happens automatically when you
_load_ a .elc file, not when you compile it.

Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Emanuel Berg]

Eli Zaretskii wrote:

>> Is my understanding of the documentation - that native
>> compilation is an automatic side effect of byte
>> compiling, wrong?
>
> Yes, it's wrong. Native compilation happens automatically
> when you _load_ a .elc file, not when you compile it.

It doesn't happen when you byte-compile but it also don't
happen when you load it, or that depends what you mean
by "load"ing.

To `load-file' an .elc does not trigger native compilation of
as we have said in this thread (and it is correct), I know
this because all my files are byte-compiled but not all of
them are natively compiled.

My theory was that it only happens when you `require' the
.elc, possibly it also requires that the file you `require'
from is also natively compiled? But then, again, I don't
understand how it all starts?

Madhu: For you to do the test on the natively compiled code,
look in your dir of cached natively compiled files,

  ~/.emacs.d/eln-cache/

and run the file from there with the shell command:

  $ emacs -Q -batch -l fib.el                    [8.660 s]
  $ emacs -Q -batch -l fib.elc                   [3.386 s]
  $ emacs -Q -batch -l fib-54a44480-bad305eb.eln [3.159 s]
  $ sbcl -l fib.cl                               [0.004 s]

Now, when looking at it, I'm unsure if I made a mistake in
test #2, i.e. the fib.elc file, because maybe if the natively
compiled file, the .eln, was present, in fact that was run
there as well?

I'll investigate this further God willing but that is a side
show, the straightforward way is still to just natively
compile everything - since we know that is the fastest way to
run Elisp code anyway - and then compare that to SBCL/CL.

All is in this file:

  https://dataswamp.org/~incal/emacs-init/fib.el

-- 
underground experts united
https://dataswamp.org/~incal

Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Emanuel Berg]

>>> Is my understanding of the documentation - that native
>>> compilation is an automatic side effect of byte
>>> compiling, wrong?
>>
>> Yes, it's wrong. Native compilation happens automatically
>> when you _load_ a .elc file, not when you compile it.
>
> It doesn't happen when you byte-compile but it also don't
> happen when you load it, or that depends what you mean
> by "load"ing.

Here it says:

  Native-Compilation is implemented as a side effect of
  byte-compilation (see Byte Compilation). Thus, compiling
  Lisp code natively always produces its byte code as well,
  and therefore all the rules and caveats of preparing Lisp
  code for byte compilation (see Byte-Compilation Functions)
  are valid for native-compilation as well. [1]

Maybe it's the source of some of the above confusion regarding
byte-compilation in particular?

[1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Native_002dCompilation-Functions.html

-- 
underground experts united
https://dataswamp.org/~incal

Re: Native compilation by default? (was: Re: stats say SBCL is 78 875 % faster than natively compiled Elisp)

[Emanuel Berg]

>>> Is my understanding of the documentation - that native
>>> compilation is an automatic side effect of byte
>>> compiling, wrong?
>>
>> Yes, it's wrong. Native compilation happens automatically
>> when you _load_ a .elc file, not when you compile it.
>
> It doesn't happen when you byte-compile but it also don't
> happen when you load it, or that depends what you mean by
> "load"ing.

Use `native-compile', works for individual Elisp files -
and more.

See an example here:

  https://dataswamp.org/~incal/emacs-init/Makefile

-- 
underground experts united
https://dataswamp.org/~incal

Re: Native compilation by default? (was: Re: stats say SBCL is 78 875 % faster than natively compiled Elisp)

[Emanuel Berg]

>>>> Is my understanding of the documentation - that native
>>>> compilation is an automatic side effect of byte
>>>> compiling, wrong?
>>>
>>> Yes, it's wrong. Native compilation happens automatically
>>> when you _load_ a .elc file, not when you compile it.
>>
>> It doesn't happen when you byte-compile but it also don't
>> happen when you load it, or that depends what you mean by
>> "load"ing.
>
> Use `native-compile', works for individual Elisp files -
> and more.
>
> See an example here:
>
>   https://dataswamp.org/~incal/emacs-init/Makefile

Or do it from Emacs.

I now have 2162 files natively compiled!

Son, he can't handle your speed!

;;; -*- lexical-binding: t -*-
;;
;; this file:
;;   https://dataswamp.org/~incal/emacs-init/native.el
;;
;; also needed:
;;   https://dataswamp.org/~incal/emacs-init/search-regexp-in-files.el

(require 'search-regexp-in-files)

(defun native-compile-all (&optional files)
  (or files (setq files (files-as-list "~/.emacs.d/emacs-init/**/*.el")))
  (dolist (f files)
    (native-compile f) ))

;; (native-compile-all)
;; (native-compile-all (files-as-list "~/.emacs.d/elpa/**/*.el"))
;; (native-compile-all (files-as-list "/usr/local/share/emacs/30.0.50/**/*.elc"))

-- 
underground experts united
https://dataswamp.org/~incal

Re: Native compilation by default? (was: Re: stats say SBCL is 78 875 % faster than natively compiled Elisp)

[Emanuel Berg]

> Or do it from Emacs.
>
> I now have 2162 files natively compiled!

Make that 2173!

With this method:

  https://dataswamp.org/~incal/emacs-init/native.el

Side note: Since I use Emacs all the time I never cared about
startup time, really, but I know it has been an issue to some
people, so let me say that with this method, as a nice
side-effect, Emacs loads everything everything very,
very fast!

And it makes sense that it should since everything is already
natively cached.

Just try - and you will fly!

-- 
underground experts united
https://dataswamp.org/~incal

Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Tue, 21 Feb 2023 17:35:09 +0100
> 
> Eli Zaretskii wrote:
> 
> > Native compilation happens automatically when you _load_ a .elc
> > file, not when you compile it.
> 
> It doesn't happen when you byte-compile but it also don't
> happen when you load it, or that depends what you mean
> by "load"ing.

I know what I mean by it, but what do _you_ mean by it?

> To `load-file' an .elc does not trigger native compilation of
> as we have said in this thread (and it is correct), I know
> this because all my files are byte-compiled but not all of
> them are natively compiled.

Again, it depends how do you "load" it.  Please show the code or the
command you used, in their entirety.

> My theory was that it only happens when you `require' the
> .elc

It happens if you load with 'require', yes.  But it also happens if
you use 'load'.

> possibly it also requires that the file you `require'
> from is also natively compiled?

No, it doesn't have to.  If the .eln file doesn't exist, Emacs will
start a native compilation in the background (unless you have disabled
it in one of the supported ways).

> But then, again, I don't understand how it all starts?

Like I said: it starts when Emacs loads a byte-compiled file for which
there's no .eln file.

Re: Native compilation by default? (was: Re: stats say SBCL is 78 875 % faster than natively compiled Elisp)

[Emanuel Berg]

Anyway these stats speak their own language - again 78 875 % -
and that also means there should be no reason why the
Jenovah Project can't be re-initiated based on these
new premises?

Maybe the model should be modernized from a practical POV -
but I mean in theory - because if it means the foundation can
be re-asserted, there should be no reasons in terms of
technology not to persue it, right?

Or am I missing something?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Native compilation by default? (was: Re: stats say SBCL is 78 875 % faster than natively compiled Elisp)

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2023-02-23 21:13]:
> Anyway these stats speak their own language - again 78 875 % -
> and that also means there should be no reason why the
> Jenovah Project can't be re-initiated based on these
> new premises?
> 
> Maybe the model should be modernized from a practical POV -
> but I mean in theory - because if it means the foundation can
> be re-asserted, there should be no reasons in terms of
> technology not to persue it, right?

I got one thing, that I don't get it.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: Native compilation by default? (was: Re: stats say SBCL is 78 875 % faster than natively compiled Elisp)

[Emanuel Berg]

Jean Louis wrote:

>> Anyway these stats speak their own language - again 78 875 % -
>> and that also means there should be no reason why the
>> Jenovah Project can't be re-initiated based on these
>> new premises?
>> 
>> Maybe the model should be modernized from a practical POV -
>> but I mean in theory - because if it means the foundation
>> can be re-asserted, there should be no reasons in terms of
>> technology not to persue it, right?
>
> I got one thing, that I don't get it.

It had to do with replicating certain items, affectionally
called artefacts, related to the origin of humanity.

The dangers were absolutely exaggerated but so was my
reputation for "pushing the envelope" recklessly ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Madhu]

* Eli Zaretskii <83k00btcsl.fsf @gnu.org> :
Wrote on Tue, 21 Feb 2023 14:37:14 +0200:
>> From: Madhu <enometh@meer.net>
>> Date: Tue, 21 Feb 2023 12:34:21 +0530

>> Is my understanding of the documentation - that native compilation is
>> an automatic side effect of byte compiling, wrong?
>
> Yes, it's wrong.  Native compilation happens automatically when you
> _load_ a .elc file, not when you compile it.

The info manual I was looking at (info "(elisp) Native-Compilation
Functions") has this text

	"Native-Compilation is implemented as a side effect of
	byte-compilation"

In any case maybe I should file a bug? because this the behaviour I
reported doesn't meet the expectations. In a fresh emacs -Q: the
following 3 forms all load a fib.elc file from the current directory
(say "/dev/shm") without producing an eln file. ("doesn't work")

(byte-compile-file "fib.el" t)  ; doesn't work
(load-file "fib.elc")           ; doesn't work
(load "/dev/shm/fib.elc" nil nil t) ; doesn't work

The only form which works seems to be when load is called with a full
pathname after omitting the ".el" or ".elc" suffix provided there is an
elc at that location.
i.e.
(load "/dev/shm/fib")

only this form produces an eln file in the user's eln-cache directory.

Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Stefan Monnier via Users list for the GNU Emacs text editor]

> (byte-compile-file "fib.el" t)  ; doesn't work
> (load-file "fib.elc")           ; doesn't work
> (load "/dev/shm/fib.elc" nil nil t) ; doesn't work

We want the users to be able to load a `.elc` file even if a `.eln` file
has been generated.  The way the users do that is by giving to
`load` the file name *with* the `.elc` extension.  Of course, they can
also load the `.eln` file by specifying that file explicitly as well.

If you want to load "the most efficient option available", then just
don't specify any extension, and Emacs will load the `.el`, `.elc`,
or `.eln` file according to what it finds.

> The only form which works seems to be when load is called with a full
> pathname after omitting the ".el" or ".elc" suffix provided there is an
> elc at that location.

It should also work if you just (load "fib"), assuming `fib.el(c)` is
found somewhere along your `load-path`.


        Stefan

Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Emanuel Berg]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

>> (byte-compile-file "fib.el" t)  ; doesn't work
>> (load-file "fib.elc")           ; doesn't work
>> (load "/dev/shm/fib.elc" nil nil t) ; doesn't work
>
> We want the users to be able to load a `.elc` file even if
> a `.eln` file has been generated. The way the users do that
> is by giving to `load` the file name *with* the `.elc`
> extension. Of course, they can also load the `.eln` file by
> specifying that file explicitly as well.

Yes.

> If you want to load "the most efficient option available",
> then just don't specify any extension, and Emacs will load
> the `.el`, `.elc`, or `.eln` file according to what
> it finds.

Cool!

>> The only form which works seems to be when load is called
>> with a full pathname after omitting the ".el" or ".elc"
>> suffix provided there is an elc at that location.
>
> It should also work if you just (load "fib"), assuming
> `fib.el(c)` is found somewhere along your `load-path`.

Again cool.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Eli Zaretskii]

> From: Madhu <enometh@meer.net>
> Date: Sun, 26 Feb 2023 08:38:49 +0530
> 
> * Eli Zaretskii <83k00btcsl.fsf @gnu.org> :
> Wrote on Tue, 21 Feb 2023 14:37:14 +0200:
> >> From: Madhu <enometh@meer.net>
> >> Date: Tue, 21 Feb 2023 12:34:21 +0530
> 
> >> Is my understanding of the documentation - that native compilation is
> >> an automatic side effect of byte compiling, wrong?
> >
> > Yes, it's wrong.  Native compilation happens automatically when you
> > _load_ a .elc file, not when you compile it.
> 
> The info manual I was looking at (info "(elisp) Native-Compilation
> Functions") has this text
> 
> 	"Native-Compilation is implemented as a side effect of
> 	byte-compilation"

It goes on by saying

  Thus, compiling Lisp code natively always produces its byte code as well

So the above has nothing to do with _when_ does native compilation
happen.  It just says _how_ it works: by launching a byte-compilation
and using its by-products internally to produce native code.

> In any case maybe I should file a bug? because this the behaviour I
> reported doesn't meet the expectations. In a fresh emacs -Q: the
> following 3 forms all load a fib.elc file from the current directory
> (say "/dev/shm") without producing an eln file. ("doesn't work")
> 
> (byte-compile-file "fib.el" t)  ; doesn't work
> (load-file "fib.elc")           ; doesn't work
> (load "/dev/shm/fib.elc" nil nil t) ; doesn't work

This is a feature, so filing a bug report against it won't be useful.
Think about it: if the above would load a .eln file instead, how would
a Lisp program be able to force Emacs to load a .elc file?

Therefore, when you specify an explicit extension, be it .el or .elc,
Emacs loads that specific file, nothing more, nothing less.  Exactly
like '(load "foo.el")' in previous versions of Emacs always loaded the
.el file, even if the .elc file was available.

> The only form which works seems to be when load is called with a full
> pathname after omitting the ".el" or ".elc" suffix provided there is an
> elc at that location.
> i.e.
> (load "/dev/shm/fib")
> 
> only this form produces an eln file in the user's eln-cache directory.

That's how it is supposed to work.

Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Eli Zaretskii]

> Date: Sat, 25 Feb 2023 23:32:43 -0500
> From:  Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> > The only form which works seems to be when load is called with a full
> > pathname after omitting the ".el" or ".elc" suffix provided there is an
> > elc at that location.
> 
> It should also work if you just (load "fib"), assuming `fib.el(c)` is
> found somewhere along your `load-path`.

Right.  And '(require 'fib)' will also work, in the sense that a
native compilation will happen if needed, and fib.eln file will be
loaded if available or after producing it.

Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Emanuel Berg]

Stefan Monnier via Users list for the GNU Emacs text editor wrote:

> If you want to load "the most efficient option available",
> then just don't specify any extension, and Emacs will load
> the `.el`, `.elc`, or `.eln` file according to what
> it finds.

I'm sure happy I read this because it made me realize despite
the mass-native compile described I still loaded the
.elc files!

Also, this makes it easier to manage, because then one don't
have to bother with paths, just `provide' every file, this can
be automated like this

(defun provide-file (&optional file)
  (interactive "fFile: ")
  (or file (setq file (buffer-file-name)))
  (goto-char (point-min))
  (let*((name (file-name-base file))
        (prov (concat "\n(provide '" name ")\n") ))
    (unless (re-search-forward prov (point-max) t)
      (goto-char (point-max))
      (insert prov)
      (save-buffer) )))

and then `load' without extension.

Man, is Emacs fast or what nowadays! Huge improvement to the
interactive feel this way ...

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Drew Adams]

[Caveat: I haven't read the doc and am not familiar
 with native compilation.  Just commenting on what
 I see written here (which is without context).  If
 what I say helps, good; if not, please ignore.]

> >  "Native-Compilation is implemented as a side
> >  effect of byte-compilation"

That says that IF you byte-compile THEN, as a side
effect of byte-compiling, native-compiling also
happens.

Actually, that statement doesn't really say that
so definitively.  It could be that the side effect
doesn't _always_ take place during byte-compiling,
but that it does sometimes, i.e., conditionally.

But a casual reading will likely assume that
native compilation occurs each time a file is
byte-compiled.

IOW, byte-compile => native compile.

The statement _could_ also be read (by assuming
that's the _only_ native-compile implementation)
as saying that IF you native-compile THEN
byte-compiling also happens - i.e., that you
can't native-compile without also byte-compiling.

IOW: native-compile => byte-compile.

It would probably be a good idea to _spell out_
exactly the relationship.  The statement as is
tries to pack too much into the few words "is
implemented as a side effect of".

> It goes on by saying
> 
>   Thus, compiling Lisp code natively always
>   produces its byte code as well

(See above.  That's the "_could_ also be read"
bit, made explicit.)

If byte-compiling always native-compiles, say so.

If the only way to native-compile is to byte-compile
(i.e., that's the _only_ implementation of native
compilation, so you can't native compile without
also byte-compiling), then say so.

> So the above has nothing to do with _when_ does native compilation
> happen.  It just says _how_ it works: by launching a byte-compilation
> and using its by-products internally to produce native code.

It doesn't really say all of that.  (Maybe some of
the rest of the doc does, but not just the snippets
shown here out of context.)  It certainly doesn't
say that you initiate the compilations (both byte
and native) by "launching a byte-compilation".  And
it says nothing about needing to use some by-products
of byte-compilation to produce native code.

Based on your last statement, a guess would be this:

Byte-compilation produces, as a side effect, some
things that can (separately) be used to perform a
native compilation.

Does a user initiate that separate native compilation?
Or does it happen automatically when you byte-compile?
(This is the first question above: does byte-compile
imply native-compile?)

Are there other ways to native-compile, besides
launching a byte-compile?

> if the above would load a .eln file instead, how would
> a Lisp program be able to force Emacs to load a .elc file?
> 
> Therefore, when you specify an explicit extension, be it .el or .elc,
> Emacs loads that specific file, nothing more, nothing less.  Exactly
> like '(load "foo.el")' in previous versions of Emacs always loaded the
> .el file, even if the .elc file was available.

This was Stefan's remark also.  It's very important.

It fits what Emacs has always done (with *.el and
*.elc), and is perfectly logical.  It should be
pointed out explicitly in the text about native
compilation and byte-compilation and loading.

HTH.

FW: [External] : Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Drew Adams]

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

[Forwarding to the list.  For some reason, "Reply All"
 with my email client replies only to Stefan.]

-----Original Message-----
Sent: Sunday, February 26, 2023 8:06 AM To: 'Stefan Monnier'

[Caveat: I haven't read the doc and am not familiar
 with native compilation.  Just commenting on what
 I see written here (which is without context).  If
 what I say helps, good; if not, please ignore.]

> > (byte-compile-file "fib.el" t)  ; doesn't work
> > (load-file "fib.elc")           ; doesn't work
> > (load "/dev/shm/fib.elc" nil nil t) ; doesn't work
> 
> We want the users to be able to load a `.elc` file even if a `.eln` file
> has been generated.  The way the users do that is by giving to
> `load` the file name *with* the `.elc` extension.  Of course, they can
> also load the `.eln` file by specifying that file explicitly as well.

If that's not already pointed out explicitly in the
doc, it would help to do so.  It can help _greatly_
to understand not only what happens but some of the
logic behind that design.  Once someone reads what
you wrote there, things are much clearer, I think.

> If you want to load "the most efficient option available", then just
> don't specify any extension, and Emacs will load the `.el`, `.elc`,
> or `.eln` file according to what it finds.

Again, please point that out explicitly (though this
one will be familiar to longtime Emacs users, as the
same logic has long existed for *.el and *.elc).

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 14821 bytes --]

Re: FW: [External] : Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 26 Feb 2023 16:14:14 +0000
> 
> > If you want to load "the most efficient option available", then just
> > don't specify any extension, and Emacs will load the `.el`, `.elc`,
> > or `.eln` file according to what it finds.
> 
> Again, please point that out explicitly (though this
> one will be familiar to longtime Emacs users, as the
> same logic has long existed for *.el and *.elc).

The logic has existed, but none of the doc strings of 'load',
'load-file', and 'load-library' says anything about it.  Neither does
the manual.  What is different here?

RE: FW: [External] : Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Drew Adams]

> > > If you want to load "the most efficient option available", then just
> > > don't specify any extension, and Emacs will load the `.el`, `.elc`,
> > > or `.eln` file according to what it finds.
> >
> > Again, please point that out explicitly (though this
> > one will be familiar to longtime Emacs users, as the
> > same logic has long existed for *.el and *.elc).
> 
> The logic has existed, but none of the doc strings of 'load',
> 'load-file', and 'load-library' says anything about it.  Neither does
> the manual.  What is different here?

I won't argue about it.  I can say that when
I read the doc of those functions (long ago)
I never had any doubt that Emacs "would load
the .el or .elc according to what it finds."

I wasn't aware that the discussion here is
only about doc strings.  Whether, and if so
then which, doc strings should mention this
is an open question.  I was talking about
the doc in general, not just doc strings.

But you also say "neither does the manual".  

To me, the Emacs manual is (and has long been)
very clear about this.  Node `Lisp Libraries'
goes into it, pointing out explicitly which
files (*.el or *.elc) get loaded (priority)
by `load', `load-library', and `load-file'.

And that Emacs-manual text points to the more
detailed text in the Elisp manual, node `How
Programs Do Loading'.

So it's not clear to me what you mean by
"neither does the manual".

If that (or similar) doc in the manuals has
been updated to say what's involved wrt *.el,
*.elc, and *.eln, then great.

In that case, perhaps the user confusion shown
in this thread could have been dispelled just
by pointing to the (updated) manuals?

And perhaps some of the doc about compilation
has been updated similarly?

(It also wouldn't hurt for the doc strings of
the various functions (e.g. `load') to link
to a manual.)

Bottom line: Maybe a little more clarification
would help.  Or else maybe it would have been
enough to point to the doc sections that you
think already clear up the confusion exhibited.
You decide.

Re: FW: [External] : Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Sun, 26 Feb 2023 17:12:56 +0000
> 
> But you also say "neither does the manual".  
> 
> To me, the Emacs manual is (and has long been)
> very clear about this.  Node `Lisp Libraries'
> goes into it, pointing out explicitly which
> files (*.el or *.elc) get loaded (priority)
> by `load', `load-library', and `load-file'.

But none of that says anything about explicitly loading FOO.el.

> And that Emacs-manual text points to the more
> detailed text in the Elisp manual, node `How
> Programs Do Loading'.

Which again says nothing about explicitly loading FOO.el.

RE: FW: [External] : Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Drew Adams]

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

> > But you also say "neither does the manual".
> >
> > To me, the Emacs manual is (and has long been)
> > very clear about this.  Node `Lisp Libraries'
> > goes into it, pointing out explicitly which
> > files (*.el or *.elc) get loaded (priority)
> > by `load', `load-library', and `load-file'.
> 
> But none of that says anything about explicitly loading FOO.el.
> 
> > And that Emacs-manual text points to the more
> > detailed text in the Elisp manual, node `How
> > Programs Do Loading'.
> 
> Which again says nothing about explicitly loading FOO.el.

Sorry, but it's not clear to me what you're
talking about.

Stefan wrote this:

 >> If you want to load "the most efficient
 >> option available", then just don't specify
 >> any extension, and Emacs will load the
 >> `.el`, `.elc`, or `.eln` file according to
 >> what it finds.

To which I suggested that that be pointed out
explicitly.  And I parenthetically added that
this logic has long existed for *.el and *.elc.

To which you replied that none of the doc
strings says anything about it [the logic
behind that behavior].

None of that discussion said anything about
"explicitly loading FOO.el".

You've apparently (now, for the first time?)
interjected the fact that the doc that talks
about the logic behind which files get loaded
in priority doesn't cover explicitly loading
FOO.el - or at least that the doc strings
don't mention that.

If you think that needs to be mentioned in a
doc string, then please add it.  It's not
clear to me what point you're trying to make
here, sorry.  Again, my suggestions are "HTH".
___

[FWIW, I think the Elisp manual (`How Programs
 Do Loading') does speak about explicitly
 loading *.el - see the part about using `load'
 and "specifying the precise file name and
 using 't' for NOSUFFIX".

 (And the doc makes clear that `M-x load-file
 FOO.el' or (load-file "FOO.el") loads FOO.el.)

 But maybe you mean something altogether
 different by "explicitly loading FOO.el"?]

[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 15657 bytes --]

Re: FW: [External] : Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Sun, 26 Feb 2023 18:29:06 +0000
> 
> > > But you also say "neither does the manual".
> > >
> > > To me, the Emacs manual is (and has long been)
> > > very clear about this.  Node `Lisp Libraries'
> > > goes into it, pointing out explicitly which
> > > files (*.el or *.elc) get loaded (priority)
> > > by `load', `load-library', and `load-file'.
> > 
> > But none of that says anything about explicitly loading FOO.el.
> > 
> > > And that Emacs-manual text points to the more
> > > detailed text in the Elisp manual, node `How
> > > Programs Do Loading'.
> > 
> > Which again says nothing about explicitly loading FOO.el.
> 
> Sorry, but it's not clear to me what you're
> talking about.
> 
> Stefan wrote this:
> 
>  >> If you want to load "the most efficient
>  >> option available", then just don't specify
>  >> any extension, and Emacs will load the
>  >> `.el`, `.elc`, or `.eln` file according to
>  >> what it finds.
> 
> To which I suggested that that be pointed out
> explicitly.  And I parenthetically added that
> this logic has long existed for *.el and *.elc.

That's not what this discussion is about.

> To which you replied that none of the doc
> strings says anything about it [the logic
> behind that behavior].

I wasn't replying to _that_.  I was replying to the main issue being
discussed: that if one specified FOO.elc, Emacs will load FOO.elc and
nothing else.  It will NOT try loading FOO.eln or FOO.el.

> You've apparently (now, for the first time?)
> interjected the fact that the doc that talks
> about the logic behind which files get loaded
> in priority doesn't cover explicitly loading
> FOO.el - or at least that the doc strings
> don't mention that.

That's the only thing being discussed here.  You are missing the main
point of this discussion, and talking about something else entirely.

>  (And the doc makes clear that `M-x load-file
>  FOO.el' or (load-file "FOO.el") loads FOO.el.)

No, it doesn't.

Re: FW: [External] : Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Emanuel Berg]

Eli Zaretskii wrote:

>> And the doc makes clear that `M-x load-file FOO.el' or
>> (load-file "FOO.el") loads FOO.el.
>
> No, it doesn't.

We need like a native compile FAQ to answer more basic
questions, in a simple way.

1. When does it happen to an individual file without you
   doing anything?

2. How do you explicitely native compile stuff, from
   a Makefile as well as from Emacs?

3. How do you load it?

4. How much faster is it than byte-compiled code? Is it around
   7% as the test say? Why is it still so much slower than
   SBCL which is 78 875% faster? Is it because Elisp has
   dynamic typing and the compiler also lacks optimizations
   that, perhaps, will come in time?

5. (And so on.)

I can answer question 2, see these files:

  https://dataswamp.org/~incal/emacs-init/native.el
  https://dataswamp.org/~incal/emacs-init/Makefile

I can also answer 3: In each file f, do

  (provide 'f)

last, then `native-compile' it, then do (load "f").

-- 
underground experts united
https://dataswamp.org/~incal

Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Madhu]

* Stefan Monnier via Users list for the GNU Emacs text editor <jwv8rglm4oz.fsf-monnier+emacs@gnu.org> :
Wrote on Sat, 25 Feb 2023 23:32:43 -0500:

>> (byte-compile-file "fib.el" t)  ; doesn't work
>> (load-file "fib.elc")           ; doesn't work
>> (load "/dev/shm/fib.elc" nil nil t) ; doesn't work
>
> We want the users to be able to load a `.elc` file even if a `.eln` file
> has been generated.  The way the users do that is by giving to
> `load` the file name *with* the `.elc` extension.  Of course, they can
> also load the `.eln` file by specifying that file explicitly as well.
>
> If you want to load "the most efficient option available", then just
> don't specify any extension, and Emacs will load the `.el`, `.elc`,
> or `.eln` file according to what it finds.


All that is fine, but the question was about producing the eln file in
the first place.  The documentation and the information posted here
indicated it will be produced when the elc file is loaded.

That explicitly does not happen in those cases I enumerated above, and
in some other cases.

The backstory is I wanted to test something without putting it
load-path.

Re: Native compilation by default?: Was [Re: stats say SBCL is 78 875 % faster than natively compiled Elisp

[Stefan Monnier via Users list for the GNU Emacs text editor]

> All that is fine, but the question was about producing the eln file in
> the first place.  The documentation and the information posted here
> indicated it will be produced when the elc file is loaded.
>
> That explicitly does not happen in those cases I enumerated above, and
> in some other cases.

I'm not familiar with the details of that code, sorry.

> The backstory is I wanted to test something without putting it
> load-path.

IIUC whether it's in `load-path` or not shouldn't make any difference.
The only relevant part is whether you give the .el/elc extension to
`load` or whether you rely on `load-suffixes` instead.

I expect (load "....elc") should *not* native-compile the file, since it
would not load it either.

        Stefan