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

91–100 of 138 posts

Re: Bringing GNU Emacs to Native Code (2020)

#91

Post by wtetzner »

zelphirkalt wrote: post #76
samus wrote: post #61

Earlier quoted context omitted.

Emacs is definitely capable of multithreading. Still using a single thread might actually be a boon because it simplifies the programming model. Right now, Elisp code can work under the assumption that there is only one thread accessing editor state at the same time. Disentangling this is probably going to be difficult, but the Emacs folks are probably smart enough to come up with something that matches with the spir…

To outsource things step-by-step to lightweight processes seems to be a good incremental way to disentangle. Perhaps one could protect access to resources not initially invented by Emacs packages (Emacs core?) and make Emacs query a separate process, without a package knowing about that, so that it channels all communication to the separate process. Then deprecate directly the resource at some point and offering a mo…

In terms of LSP, I don’t think there’s anything particularly novel about it. It’s really only better than other similar protocols in the sense that it is gaining in popularity. I.e., the biggest thing that was missing is consensus on a shared protocol.

In terms of the protocol itself, I suspect it’s actually worse than a lot of other ones.

Re: Bringing GNU Emacs to Native Code (2020)

#92

Post by Siira »

volta83 wrote: post #38
DDSDev wrote: post #6

I think that nativecomp represents a huge leap forward for emacs. I continually give kudos to Andrea Corallo and the entire team for making this a possibility. I think that the next major leap for emacs needs to involve the garbage collector and allocation logic. I think that a large class of performance optimizations would be possible with an improved GC, including improvements to emacs existing threading capabiliti…

I think nativcomp doesn't really improve what makes emacs "slow". Emacs is a single threaded synchronous and blocking UI system. Sometimes when my autocomplete, C++ checking, git checking, auto formating, ... run, the editor freezes, for multiple seconds. All this stuff runs in the UI thread. Braindamaged. The other thing that makes emacs slow is remote editing. Emacs TRAMP uses one ssh connection per command. VS Cod…

VSCode's remote editing simply does not work on unstable networks. Tramp works like a champ in those situations.

Re: Bringing GNU Emacs to Native Code (2020)

#93

Post by jonnycomputer »

riffraff wrote: post #90
wyuenho wrote: post #49

Earlier quoted context omitted.

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.

I think you want to do port install emacs-devel +nativecomp or port install emacs-app-devel +nativecomp

I did this last night. It failed to compile. OSX 10.14. Frustratingly.

Re: Bringing GNU Emacs to Native Code (2020)

#94

Post by Siira »

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…

It's your own setup's fault. I use emacs daily, and I almost never have to restart it.

Re: Bringing GNU Emacs to Native Code (2020)

#95

Post by zucker42 »

volta83 wrote: post #38
DDSDev wrote: post #6

I think that nativecomp represents a huge leap forward for emacs. I continually give kudos to Andrea Corallo and the entire team for making this a possibility. I think that the next major leap for emacs needs to involve the garbage collector and allocation logic. I think that a large class of performance optimizations would be possible with an improved GC, including improvements to emacs existing threading capabiliti…

I think nativcomp doesn't really improve what makes emacs "slow". Emacs is a single threaded synchronous and blocking UI system. Sometimes when my autocomplete, C++ checking, git checking, auto formating, ... run, the editor freezes, for multiple seconds. All this stuff runs in the UI thread. Braindamaged. The other thing that makes emacs slow is remote editing. Emacs TRAMP uses one ssh connection per command. VS Cod…

> All this stuff runs in the UI thread. Braindamaged.

Calling this "braindamaged" is hardly fair; I'm sure this decision was made ~35 years ago when it made more sense.

Re: Bringing GNU Emacs to Native Code (2020)

#96

Post by rgrau »

da39a3ee wrote: post #84

Given an installed emacs, what's the best way to check whether it was built with this feature and that the feature is active?

Several ways (overkill answer, but leaving all options I know because why not):

You can try evaluating this in the scratch buffer

    (if (member 'nativecomp features)
        (message "yay")
      (message "nay"))
Or check if a non-interactive function called `native-compile` exists.

Or open help for an elisp function (next-line, for example):

    c-h f next-line RET
Gives me:

    next-line is an interactive native compiled Lisp function in ‘simple.el’.
Or, m-x disassemble next-line RET

Re: Bringing GNU Emacs to Native Code (2020)

#97

Post by wyuenho »

rurban wrote: post #89
wyuenho wrote: post #49

Earlier quoted context omitted.

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.

Google helps: https://gist.github.com/AllenDang/f019593e65572a8e0aefc96058... Macports has gccjit since gcc10, just somebody needs to update Emacs. What others archs? All of course

Google should also help you understand that the libgcc port does not provide for libgccjit for whatever reason.

I'm writing my own Portfile to get libgccjit 11 now. The emacs-devel port does bring in the entire gcc10, but I just want libgccjit.

Re: Bringing GNU Emacs to Native Code (2020)

#98

Post by kfajdsl »

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've never experienced this. I autostart emacs in daemon mode, and right now my desktop's uptime is... 3 days. And that's only because I updated my kernel, normally I'll go for a lot longer than that.

Re: Bringing GNU Emacs to Native Code (2020)

#99

Post by kfajdsl »

ashton314 wrote: post #32
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'd bet it's just your setup. I had one Emacs session run for almost a month straight—and that was with LSP mode running on a fairly large Elixir project. I only restarted it because I needed to restart the machine I was running it on. It was using barely over 300 MB of RAM. (Lots and lots of open buffers and whatnot.) That's not an unusual occurrence for me—and I'm not even running the native-comp branch yet! FWIW,…

I basic used `:defer t` for a while (Doom Emacs lazy loaded under the hood), but when I switched to my own config I decided to just run it in daemon mode and use `:demand t` on everything. I didn't like pauses sometimes when opening a new file while it loaded a package.

Actually, I just checked my init time with that command, and it's ~2.5 seconds. I wouldn't call my config heavyweight, but it does have evil, lsp, vterm, ivy, magic, etc. I am using the native-comp branch though.

Re: Bringing GNU Emacs to Native Code (2020)

#100

Post by da39a3ee »

TeMPOraL wrote: post #63
jlarocco wrote: post #26

Earlier quoted context omitted.

Eh, I don't know... I suspect the speed up depends a lot on how a person uses Emacs. I've been using it for a few months as well, and I haven't noticed any change. My start up time, as measured with 'emacs-init-time, is 0.6-0.7 seconds instead of 0.7-0.8, but that's about all I've noticed, and there hasn't been any difference in day-to-day editting. I haven't had any problems, so that's good at least.

Definitely. Depends on how much you stuff your Emacs is running. Bare-bones Emacs was generally pretty snappy, but once you activated all the quality-of-life features and added a bunch of third-party packages, there was a noticeable performance impact. The first thing where it usually affected me was org-mode. It runs a lot of complex text-parsing and redisplay code on the buffers, and some frequently used operations…

> but once you activated all the quality-of-life features and added a bunch of third-party packages, there was a noticeable performance impact.

I'm not sure I understand what you mean there. Unless those third-party packages are scheduling tasks on the event loop then they should not be impacting performance of your other operations. Just having lots of things installed and activated doesn't affect performance.

Post reply on HN