path: root/2021/talks/native.md

[[!meta title="Emacs Lisp native compiler, current status and future developments"]]
[[!meta copyright="Copyright © 2021 Andrea Corallo"]]
[[!inline pages="internal(2021/info/native-nav)" raw="yes"]]

<!-- You can manually edit this file to update the abstract, add links, etc. --->


# Emacs Lisp native compiler, current status and future developments
Andrea Corallo


[[!inline pages="internal(2021/info/native-schedule)" raw="yes"]]

Emacs Lisp (Elisp) is the Lisp dialect used by the Emacs text editor
family.  GNU Emacs is traditionally capable of executing Elisp code
either interpreted or byte-interpreted after it has been compiled to
byte-code.

In this talk I'll discuss the Emacs Lisp native compiler.  This feature
recently merged into the main Emacs development line allow for
automatically compiling and executing Elisp as native code.

During the presentation I'll touch on:

-   design goals
-   compiler and runtime design and implementation
-   performance implications
-   upstream process
-   area of improvements and future developments

Format: 40 minutes

# Discussion

Pad:

-   Q1: Why do you say that Elisp is *nearly* a general purpose
    programming lang? What's missing? (and btw, huge thanks for your
    work!)
    -   A:
-   Q2: Is this the "rudiments" that the garbage collector talk was
    discussing yesterday? Feel free to ignore this n00b question. 
    -   A:
-   Q3:Is the idea to enventually develop Emacs itself in ELisp (c.f. 
    Smalltalk VM developed in Smalltalk)?
    -   A:
-   Q4: How did you work on this? Did you use Org Mode to keep track of
    your progress? Did you use pictures to keep track of your compiler
    transformations or you made only for the presentation? Asking
    because it seems a complex project and I am not sure how you kept
    that all in your mind! For example, make sure to pick stuff that FSF
    was okay with while also deciding how to implement the optimization.
    Great job anyway!
    -   A:
-   Q5:Is this pipeline a possible source of new security
    vulnerabilities, or a new category of vulnerabilities? Is it
    something you are worried about or have had to deal with?
    -   A:
-   Q6: What code, if any, would still benefit significantly from being
    written in C? Could/should some of the existing C code be converted
    without significant performance loss?
    -   A:
-   Q7: What's the risk of (setq native-comp-speed 3)?
    -   A: Not sigificant risks.  Some side effects might include:
        needing to recompile a whole file or compilation unit when
        redefining a function, otherwise the old function definition
        could be used.
-   Q8: Are there any limits introduced by native comp with respect to
    runtime introspectability, changeability/redefinability, etc?
    -   A:
-   Q9: Is there a benefit in setting native-comp-compiler-options to 
    "-mtune=native -march=<cpu>"?
    -   A: Not at the moment.  Maybe in the future if, e.g. libgccjit is
        enhanced further.
-   Q10: You mentioned native-comp coming in emacs 28, will this be the
    default at build time, or will distros have to set this themselves?
    -   A: It will not be enabled by default.  Distros would need to
        enable it themselves.(Thanks!)
-   Q11: Could we avoid libgccjit.so? Or consider using another jit lib
    (e.g. dynasm used by luajit) et al to gain better optimization
    -   A: libgccjit is more for AoT compilation, more in-depth
        optimization, which JITters don't typically do, so they aren't
        really equivalent.
-   Q12: How much of emacs C code base could be translated to
    emacs-lisp? What is the minimum C code base necessary?  (seems
    duplicate of Q6)
    -   A: Very hard questions to answer.  :)  Not generally
        feasible/worth to convert most of it.
-   Q13: could we statically type elisp code (via macros?) to provide
    more optimization hints to compiler?
    -   A: Hope to extend existing Elisp variable-type annotations to
        arguments and use that for optimization.
-   Q14: Elisp and Python all are dynamically typed langauge, but
    benchmark shows that Elisp runs slower than Python. Could we learn
    some best practices from the Python community? As you mentioned.
    make parameter type annotated is a promising point.
    -   A: Not sure if Elisp is really generally slower than Python. 
        The Elisp bytecode VM is similar in design to the Python VM. 
        Some native-compiled Elisp may already be faster than Python,
        e.g. for certain math code.
-   Q15: Did you try to optimize with Rust too? What are your thoughts
    on Rust for this particular optimization and security?
    -   A: Optimize what?  There is no Rust here.  :)  Rust is
        interesting, though.  There may be some possibilities, e.g. with
        regard to some similarities between Rust and some CL
        implementations.
-   Q16: Why not implement Emacs Lisp in Guile and use Guile's
    compiler?
    -   A: (not Andrea answering) This has already been tried and done,
        lookup Guilemacs, e.g. on EmacsWiki.
        -   A: I think they meant to implement Elisp in Guile, and not
            to replace Elisp with Scheme
            -   Yes, that's already been done.  Guile can already run
                some subset of Elisp.  Look it up.  :)

BBB:

- Where did funding for your work came from? Will you be able to maintain this in the foreseeable future?
- akrk: What kinds of applications do you envision native-comp enabling to work well in Emacs in the next few years, that wouldn't otherwise be possible?
- Is this the first real-world practical use of libgccjit?
- Is there any  easy tasks you need help with?
- yes, your updates and communication with the community have been great
- I believe, going by the aliases, there's at least a couple of GNU compiler hackers in this BBB room now :)
- you mentioned that these improvements are orthogonal to the garbage collector. Do you know of any work on that area?
- hmmm XEmacs got a new GC, much better -- and it turned out *slower* than the original. This stuff is hard...
  - NullNix: Really?  Yesterday Stefan mentioned XEmacs's GC and said that it could be used in GNU Emacs
  - Alas, quite noticeably slower :( cache locality, probably. It may be possible to make it faster with more work, though, while the existing Emacs one is probably at its implementation limits.
  - IIRC, the XEmacs one was a generational GC. It was a long time ago though, ICBW
  - The JDK and Go both have interesting GC designs in this area...
- some level of "naive" optimism is necessary to start working on these big projects :)
- what kind of packages do you think could be now practical with native comp?
- ok, but what are the limits, in your opinion? How fast can elisp go?
- relevant link: <https://www.emacswiki.org/emacs/GuileEmacs> (with caveats. lots of caveats).  note: guile has native support for elisp -- but the lack of buffers, the different rep with strings, etc, was *hard*. the guile compiler changed a *lot* in v3. v1.8 -&gt; 2.0 -&gt; 2.2 -&gt; 3.0 were all big changes in the guile comp world
- indeed :)
- What are some other hobbies/interests of yours besides Emacs?
  - Questioner: cool, reminds me of Thierry Volpiatto who's a professional climber, and there are several Emacsers who do DJing; that would be fun; "Emacs Plumbers Conf"; 
- will you be presenting there or anywhere else in the next year?
- Emacs keeps creeping toward being the Lisp Machine of the 21st century :)
  - not only that, but with LSP and things like Doom, there is an increasing appeal for Emacs as an editor for the general public; native compilation will help with that
- (Probably a live question)
  - yes, myths about emacs-devel are hard to dispel
  - Eli is so patient with the people on Reddit :D
  - agreed, we owe him a lot
- I've always wanted to do Emacs trading cards; like features, devs, etc :P
  - that's a great idea :D
  - I designed some for an old gaming clan years ago, it was a lot of fun
  - Not American?~; in the US we have a tradition of baseball, and other sport playing cards, each with a picture and some stats on the back
  - we have that with football (real football) in Europe :)
- (Probably live question
  - there might be even more from RMS that weren't accounted for as separate commits when the repo was converted to git
- Where is the pre-git repository?
  - I thought it was from bzr.
  - I don't remember the details, but ESR's written about it on his blog IIRC
- do you have 'wish list' features, things you long for Emacs to be able to do?
- look for posts about reposurgeon
- dickmao has a patch that makes Gnus async.... 8k lines from what I've heard
  - I recall that dickmao posted it to the Emacs tracker but it was somewhat monolithic and wasn't well accepted
  - i think he was asked to break it down to more reviewable units
- One thing I wondered if you wanted to talk more about andrea was, to the prior point about "myths" about what emacs-devel is "like", there's also "make the culture your own". do you have advice on how to approach the community you haven't gotten to yet?

BBB feedback:

- Extremely impressive work, Andrea. Also, very needed for the long term sustainability of the platform. Thanks a lot for the hard work!
  - Yes, if there were an Emacs Hall of Fame, Andrea would deserve a prominent place in it.  :)
  - we really do need an Emacs Hall of Fame so we can remember those who laid the foundations
- I think I can safely say that we are very grateful for your work, because there aren't many people in the world that could do it and who also have enough interest in Emacs to do so :)
- I have to go, thanks for replying to our questions, for the chat and for the incredible work, Andrea
- Thanks very much, and for your work on gccmacs :D
- thanks for the presentation and answering all of the questions.
thanks to you andrea for your awesome talk, and for the extended q&a!

IRC nick: akrl
- What's the risk of (setq native-comp-speed 3)? will it melt my cpu?
  - The same as the risk of using -O3 with gcc. It gives itself the latitude to aggressively optimise away code elements which it believes are unnecessary, up to and including violating the language semantics of lisp (which gcc doesn't inherently care about). -O3 is something which is fine for specific cases where you test afterwards, but you would never, for example, set -O3 globally in Gentoo.
- so we can get type annotations in Elisp?!
- Is there a benefit in setting native-comp-compiler-options to "-mtune=native -march=<cpu>"?
- Would Eli agree on replacing the C parts of Emacs with Elisp? ;)
- Why not implement Emacs Lisp in Guile and use Guile's compiler?
  - https://www.emacswiki.org/emacs/GuileEmacs
    - guile elisp is a very-long-term project, but so far has never been good enough: the problem seems to be, alas, time overhead involved in bidirectional conversion of strings and things like that: and unfortunately Emacs is all about strings... guile can run elisp (or something very like it) but that's not anywhere near replacing the elisp interpreter...

Feedback:

- what a great talk. this will rise the hype for emacs 28
- This work is really amazing. Congratulations on the effort and the deep insights that made this possible.
- excellent presentation and work that will be greatly appreciate by all Emacs users.
- It is very humbling to see this depth of knowledge and how it positively impacts my day to day computing experience.
- this is a very interesting update on his talk at last year's GNU Tools Track at LPC :)
- The worse thing about native comp is that you get used to it after a couple of days and you don't appreciate it anymore! ;) which is not fair...

[[!inline pages="internal(2021/captions/native)" raw="yes"]]

[[!inline pages="internal(2021/info/native-nav)" raw="yes"]]