Andrea Corallo

gccemacs is amazing! I've been using for more than a year on macOS and NixOS, and it's been superb (though from time to time I clear downloaded packages and the native cache just in case). It's definitely an impressive feat of engineering as well. If you haven't seen the developer's website on it[0], you should definitely check it out. For Nix users on macOS, see[1]. Here's how I used it in my home-manager config[2]. For Nix users on Linux and NixOS, see the Emacs overlay[3]. There's even Emacs nativecomp + wayland support (emacsPgtkGcc) there. [0] https://akrl.sdf.org/gccemacs.html [1] https://github.com/twlz0ne/nix-gccemacs-darwin [2] https://github.com/siraben/dotfiles/blob/8161e1b72965b48f8223fd4624554… [3] https://github.com/nix-community/emacs-overlay

If one is looking to improve Emacs performance, I would recommend checking out gccemacs https://akrl.sdf.org/gccemacs.html insteald, as guilemacs has stalled. gccemacs has been merged into the main emacs branch and works by compiling Elisp into dynamically loadable binaries. The performance speedups are very promising, with up to 30x speed improvements over standard byte code. I've been using it as my default emacs and it's been working very well. No crashes and Emacs is finally not slow! Now all Emacs needs is preemptive multi-threading!

Well, one of the major points of Guile (speed) is becoming obsolete as people are working in native-compiling elisp with libgccjit[0]. It provides great speed benefits: an average of x3~4 and up to ~x20 on recursive functions. With type annotations we can speed it up more — no need for a Guile JIT for speed anymore. [0]: https://akrl.sdf.org/gccemacs.html

After trying Typed Clojure, liking it, but giving it up because of Clojure's GPL-incompatible license, I got interested in Kawa Scheme because it has some rudimentary form of type checking. For example, this produces warnings: (define (f1 x::String y::String) (x:concat y)) (define (f2) (f1 3 3)) ;; /dev/tty:3:19: warning - type integer is incompatible with required type java.lang.String ;; /dev/tty:3:21: warning - type integer is incompatible with required type java.lang.String ;; /dev/tty:3:15: warning - cannot convert literal (of type gnu.math.IntNum) to Type java.lang.String ;; /dev/tty:3:15: warning - cannot convert literal (of type gnu.math.IntNum) to Type java.lang.String Unfortunately it does not support fully static type checking nor generics, otherwise it would be my favorite scripting language hands down. As for type checking Elisp, Elsa[1] seems an interesting project and I hope it becomes a stable option. On the other hand I wonder if in future type checking could also come from gccemacs[2], since one of the "long-term improvements" may be "better compile time warning and errors relying on the propagation engine". [1] https://github.com/emacs-elsa/Elsa [2] https://akrl.sdf.org/gccemacs.html Edit: grammar.

Emacs lisp can be compiled into bytecode (*.elc files) for faster execution. Native compilation takes bytecode and compiles (all while doing some smart things like type and value propagation) it into machine code utilising libgccjit. This results in some very nice speed gains. The author described the project in his blog here: https://akrl.sdf.org/gccemacs.html

Emacs Lisp now arguably has a better type inferencing compiler than SBCL[1]. [1] http://akrl.sdf.org/gccemacs.html#orge596749

There are some benchmarks here (elisp-benchmarks package): https://akrl.sdf.org/gccemacs.html

Asking as wasn't mention, was fib compiled with comp-speed 3? That should be considerably relevant in this benchmark. PS you can also run a wider set of benchmarks to compare against stock Emacs using: https://elpa.gnu.org/packages/elisp-benchmarks.html Here some not very updated results: http://akrl.sdf.org/gccemacs.html#org4297f0f

There’s a lot more detail on how this works in these slides from the author of the native elisp feature branch: http://akrl.sdf.org/gccemacs_els2020.pdf

With https://akrl.sdf.org/gccemacs.html#orgfc80a25 being the relevant starting point in that sea of text (the PKGBUILD is also handy for seeing what's going on: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=emacs-native-co… )

I second every single line of this comment. Here's the update log of the project. https://akrl.sdf.org/gccemacs.html

> The core-architecture remains the same https://akrl.sdf.org/gccemacs.html as posted already in this thread, compiling more of emacs with gcc, very interesting change to the core architecture. > the old problems remain the same. from the linked article - Lexical-binding is used by default - Portable dumping used instead of unexec What exactly are you talking about?

This is a stalled project, interesting but stalled. There are changes happening elsewhere, for example the obligatory rust mashup: https://github.com/remacs/remacs gccemacs is probably the most interesting recent development: https://akrl.sdf.org/gccemacs.html

Note: this is a video. Here are the slides: http://akrl.sdf.org/gccemacs_els2020.pdf

Honest question: what are the benefits of Guile Emacs in 2020 and after? Guile speed? I'm aware Guile (especially) later versions got really good VM and general optimizations, but with recent work in gccemacs [1] and having complete gcc optimization engine under the belt, can these two be even compared? Also, gccemacs showed you get visible speedups in some use cases only. Have everything under Guile umbrella? Remember, Guile is getting trickier and trickier to build over the years and I don't want that from scripting language whose main idea was to embed it (presumably also ship the source alongside your program in some cases). I'm getting impression even python source & build is easier to ship and you can't go below that. Also, modern Guile compilation time is abysmal. I recently ditched Guix [2] from my system because bootstraping on fairly modern laptop would take hours, mainly because Guile is trying to compile some helper scheme libraries needed for guix to work and recompile everything again with 2-3 different gcc versions (which are bootstraped too). [1] http://akrl.sdf.org/gccemacs.html [2] https://guix.gnu.org/