Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bringing GNU Emacs to Native Code (2020)

arxiv.org

Post reply on HN
Print view View original

41–50 of 138 posts

Re: Bringing GNU Emacs to Native Code (2020)

#41

Post by tejuis »

the_duke wrote: post #18

Every time I try Emacs I get annoyed by it's slowness and go back to vim and VS Code. This might entice me to build it and try out my Emacs Doom setup again.

There are number of things you can do to improve your situation. Obviously you should not have packages loaded that you don't rely use. There are also ways to perform "lazy" loading, so that memory image is minimal until a package is really needed. I'm not using this myself.

My usage model is such that I only start one Emacs and use emacsclient to add files for editing from terminals. Emacs is running all the time (weeks/months).

Since Emacs is my primary interface to my Linux box, I give it some priviledges. In the .xsession I do:

vmtouch -t $HOME/.emacs.d; vmtouch -ld /usr/bin/emacs-gtk

Which effectively ensures that critical Emacs images and data is present in the memory all the time. Check out vmtouch utility. It might be useful for other purposes as well.

Re: Bringing GNU Emacs to Native Code (2020)

#43

Post by siraben »

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/8161e1b72965b48f822...

[3] https://github.com/nix-community/emacs-overlay

Re: Bringing GNU Emacs to Native Code (2020)

#44

Post by josteink »

rubyn00bie wrote: post #31

I'm 100% not trolling with this question, I really like Emacs, buuut: Does it fix having to restart Emacs after at most 8-16 hours of use? Could this experience be a plugin I use, or my own idiocy? Originally, I assumed "YES! Of course! I am idiot... This is my fault!" Then came the observation when pairing with people (across a variety of languages) who use Emacs, who all say on a regular basis, without so much as a…

> Could this experience be a plugin I use, or my own idiocy?

Considering how lots of people prefer to start Emacs once, preferably as a server (maybe even as a systemd user-unit!), and keep it running forever, not even closing buffers, until eventually the machine must be rebooted for whatever reason...

I would have to say yes.

Re: Bringing GNU Emacs to Native Code (2020)

#45

Post by rurban »

wyuenho wrote: post #27
TacticalCoder wrote: post #2

The speedup is very noticeable. Like others I'm running the "native-comp" branch of Emacs, since months, without any issue. It's now been merged into trunk and it's going to be the default: https://news.ycombinator.com/item?id=26935401 The only drawback I saw is that compiling Emacs itself takes 3x to 4x longer when compiling the native-comp branch.

It seems to still have trouble compiling code using old-style advices. By not supporting LLVM JIT, this also brings in a lot of extra dependencies on macOS, although, not as egregious as librsvg.

By not supporting LLVM JIT it gains a lot of significant advantages:

Small jit dependency. 1MB compared to 30MB.

Fast JIT. At least 3x faster than llvm.

All architectures. LLVM only supports a tiny amount of architectures, gccjit all.

Only the desperate do llvm jitting.

Re: Bringing GNU Emacs to Native Code (2020)

#46

Post by rurban »

harles wrote: post #42

Genuine question: why is this on Arxiv? It seems like a design document in the format of a research paper.

It's the submission paper to the 13th European Lisp Symposium (ELS20) last year in Zurich. Lisp conferences put a higher demand on their submissions to be like formal papers. With external reviewers and such. This is one.

At this stage nativecomp was not yet finished, see his webpage for the progress. Expect another paper for the final evaluation of the improvements. It has big impact on programming languages implementations, esp. compared to llvm.

It's the very first big gccjit project, and a huge success.

Re: Bringing GNU Emacs to Native Code (2020)

#47

Post by nick_kline »

rubyn00bie wrote: post #31

I'm 100% not trolling with this question, I really like Emacs, buuut: Does it fix having to restart Emacs after at most 8-16 hours of use? Could this experience be a plugin I use, or my own idiocy? Originally, I assumed "YES! Of course! I am idiot... This is my fault!" Then came the observation when pairing with people (across a variety of languages) who use Emacs, who all say on a regular basis, without so much as a…

I never need to restart emacs. It's generally only when I reboot that I have to start emacs again.

Re: Bringing GNU Emacs to Native Code (2020)

#48

Post by [deleted] »

darthrupert wrote: post #25
TacticalCoder wrote: post #21

Earlier quoted context omitted.

> Is the speedup during editing or does it also improve startup time? During editing/usage for sure: it is noticeable. Not that it was slow before but nearly everything now feels really snappy. As for startup I don't know as I rarely relaunch it but I just tried (only for the native-comp branch): time emacs -Q -eval '(kill-emacs)' gives 160 ms. Or launching Emacs with -Q and then calling emacs-init-time gives basical…

Emacs has been pretty slow in editing, ever since Visual Code came along to set the bar higher. Good thing that Emacs is back in the game though, that editor has heart.

[deleted]

Re: Bringing GNU Emacs to Native Code (2020)

#49

Post by wyuenho »

rurban wrote: post #45
wyuenho wrote: post #27

Earlier quoted context omitted.

It seems to still have trouble compiling code using old-style advices. By not supporting LLVM JIT, this also brings in a lot of extra dependencies on macOS, although, not as egregious as librsvg.

By not supporting LLVM JIT it gains a lot of significant advantages: Small jit dependency. 1MB compared to 30MB. Fast JIT. At least 3x faster than llvm. All architectures. LLVM only supports a tiny amount of architectures, gccjit all. Only the desperate do llvm jitting.

Besides ARM and AMD64, what other arch do you need to support? RISC-V?

I'm using MacPorts and I have no idea how to hand compile just libgccjit there. The libgcc port doesn't even produce the jit language.

Re: Bringing GNU Emacs to Native Code (2020)

#50

Post by geokon »

darthrupert wrote: post #25
TacticalCoder wrote: post #21

Earlier quoted context omitted.

> Is the speedup during editing or does it also improve startup time? During editing/usage for sure: it is noticeable. Not that it was slow before but nearly everything now feels really snappy. As for startup I don't know as I rarely relaunch it but I just tried (only for the native-comp branch): time emacs -Q -eval '(kill-emacs)' gives 160 ms. Or launching Emacs with -Q and then calling emacs-init-time gives basical…

Emacs has been pretty slow in editing, ever since Visual Code came along to set the bar higher. Good thing that Emacs is back in the game though, that editor has heart.

last I tried VSCode there was a noticeable input lag (keystroke to character on screen). Is there some trick to fix this?

I found it incredibly distracting. In Emacs... Magit is instantaneous while orgmode tangle/export is embarrassingly slow - but never a dealbreaker

anecdotally eshell has some of the lowest latencies as well https://danluu.com/term-latency/

Post reply on HN