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

Bringing GNU Emacs to native code [video]

toobnix.org

Post reply on HN
Print view View original

41–50 of 84 posts

Re: Bringing GNU Emacs to native code [video]

#41

Post by morelisp »

aasasd wrote: post #33
s-km wrote: post #24

Earlier quoted context omitted.

does it do anything to change/fix Emacs shitting itself on large buffers? last time i gave it a try opening a large file would completely kill performance, and iirc in particular really long lines (ex. 1000+ chars) would make the thing chug even if the actual file wasn't super big or anything.

> in particular really long lines (ex. 1000+ chars) would make the thing chug My uninformed guess is, this is bottlenecked by an inefficient algorithm that accesses the memory too much, i.e. it's nonlinear with respect to the number of characters. I doubt that tweaking the overall speed would fix it.

My experience is it's generally either

- inefficient font-lock regexes, which are rarely benchmarked / optimized since most files don't have long lines and because font-lock behavior is quite complicated to begin with;

- inefficient thing-at-point implementations / use, e.g. an O(n*n) thing-at-point called at various points by an O(n) function;

- modes using font-lock regexps where they really just need "fixed" styled text, but other Emacs architecture makes it difficult, e.g. compilation-mode and derivatives.

Re: Bringing GNU Emacs to native code [video]

#42

Post by metroholografix »

mikelevins wrote: post #34
metroholografix wrote: post #23

Earlier quoted context omitted.

It hasn't already been done, no. The Emacs variants you mentioned (that IMV should not be referred to as "Emacs") are from-scratch new implementations of just the concept behind Emacs, but not GNU Emacs itself. They are not compatible with GNU Emacs, they don't even support a small fraction of GNU Emacs features, and are thus doomed to obsolescence / non-existent market share. So far, nobody -that I know of- has trie…

You appear to consider "Emacs" and "GNU Emacs" synonymous. I explicitly do not. Hemlock is not a reimplementation of GNU Emacs; it's derived from earlier Emacsen, just as GNU Emacs is. Hemlock in particular is based on ZWEI, and was in version 0.99 around the time that work started on the GNU Emacs project. It's a slightly older sibling of GNU Emacs, rather than a descendant of it. GNU Emacs has undoubtedly become th…

Sure, I just wanted to clarify and make it very clear that GNU Emacs in CL hasn't even been attempted since that was what the poster you originally replied to, equated "Emacs" with.

As you said, the value lies primarily in the ecosystem. Common Lisp is by far the better language, but GNU Emacs is by far the most empowering/practical environment. I don't think enormous work would be needed, there are plenty of powerful shortcuts one could take (some ideas are in this thread) and Emacs Lisp can be made to run on top of Common Lisp but it's safe to say that for whatever reasons the will/intent is simply not there.

Emacs Lisp is what we have to go on with and it's nice to see that it is not stagnating.

Re: Bringing GNU Emacs to native code [video]

#43

Post by philsnow »

harrygeez wrote: post #25

Just when I thought I know enough compsci to understand everything on a sufficiently high level, this guy totally lost me starting from LIMPLE

Compilers are "just" a series of transformations / translations from higher-level code to lower-level code. The top is code like C, python, elisp, whatever, and the bottom is machine code for amd64, arm7, whatever. All the in-between code is in some intermediate representation (IR).

Each successive step takes care of different optimizations, modifying the code as it goes down. At the last step, he converts LIMPLE to an IR (intermediate representation) that libgccjit understands, and hands it off to gcc for native compilation.

Could you just start with elisp and emit amd64 machine code in one step? Absolutely, but it would be hell to maintain, and then you lose out on all the pluggability of modern compilers. If you (consume and/or) emit standard(-ish) IRs, you get to participate in a pretty amazing ecosystem.

Re: Bringing GNU Emacs to native code [video]

#44

Post by tptacek »

metroholografix wrote: post #32
gpderetta wrote: post #30

As a exclusive emacs user for the last 20 years, I'm quite excited; my main complain about emacs is its slow down with some more sophisticated packages. I wonder if it improves magit performance with large codebases. Pigs fly just fine with with enough thrust.

One reason magit is slow (that last I checked still hasn't been fixed) is that it spawns a large number of processes calling out to git for each operation. Most of these are redundant and could/should go away with either a redesign or a working caching scheme. This issue is more than obvious on platforms (e.g. some macOS versions) where fork/vfork are not as fast as one would expect. I like the paradigm behind magit,…

You can somewhat fix the macOS Magit perf problem --- at least the Aquamacs one --- by patching the vfork in the source. Doing that took me from keystroke-lag speed to regular interactive speed (but I've since switched to railwaycat Emacs, which I don't think has the problem, though maybe I just don't notice it).

Re: Bringing GNU Emacs to native code [video]

#45

Post by tptacek »

metroholografix wrote: post #40
travisjeffery wrote: post #38

Earlier quoted context omitted.

Magit is working on switching to libgit2 https://github.com/magit/magit/issues/2959 to fix this.

This issue has been open since 2017 and it's not panacea since it comes with its own -substantial- tradeoffs which is why as far as I know, magit is not "switching to libgit2" but planning to offer libgit2 as an additional option. Also for such an important feature, rather than going with FFI, it would be much better if Emacs linked with libgit2 (similarly to the improved JSON support in 27). That way the core Emacs…

Why do I want the Emacs team reviewing libgit2 or Magit?

Re: Bringing GNU Emacs to native code [video]

#46

Post by rurban »

bjoli wrote: post #19
ufo wrote: post #17

Earlier quoted context omitted.

I would expect that an ELisp interpreter written in Common Lisp would likely be slower than the existing ELisp interpreter written in C. As for compilation to Common Lisp, I don't know how feasible it would be. Apparently they tried something similar with Guile and it ran into problems.

Guile (the VM) runs elisp just fine. There has been zero optimization work done though so it is quite slow. The reason they did not go with guile was more political than anything else. It was also understandable from their point of view (and I say this as a guile weenie)

No, the reason is still slow string buffers. Politically everybody wants emacs to switch to guile.

Re: Bringing GNU Emacs to native code [video]

#47

Post by hvis »

metroholografix wrote: post #32
gpderetta wrote: post #30

As a exclusive emacs user for the last 20 years, I'm quite excited; my main complain about emacs is its slow down with some more sophisticated packages. I wonder if it improves magit performance with large codebases. Pigs fly just fine with with enough thrust.

One reason magit is slow (that last I checked still hasn't been fixed) is that it spawns a large number of processes calling out to git for each operation. Most of these are redundant and could/should go away with either a redesign or a working caching scheme. This issue is more than obvious on platforms (e.g. some macOS versions) where fork/vfork are not as fast as one would expect. I like the paradigm behind magit,…

Meaning, it's only really slow on macOS.

Re: Bringing GNU Emacs to native code [video]

#48

Post by WhatIsDukkha »

gpderetta wrote: post #27
slightwinder wrote: post #20

Earlier quoted context omitted.

I wonder whether a modern modularized architecture might be the better way to handle this. Similar to neovim where you have a backend which communicates with a detatched frontend and other backends over some rpc-mechanism. Refactor the existing emacs to work headless and become the legacy-core, while also establishing channels to attatch any other core and frontend.

An important optimization discussed in the video is to optimize through call into C code (i.e elisp->C->elisp). adding RPC at the boundaries would go in the opposite direction.

Well this is not to my taste but I take it as a proof of existence that an rpc at the boundary could make for some amazing things -

https://github.com/rhysd/NyaoVim

Re: Bringing GNU Emacs to native code [video]

#49

Post by saagarjha »

hvis wrote: post #47
metroholografix wrote: post #32

Earlier quoted context omitted.

One reason magit is slow (that last I checked still hasn't been fixed) is that it spawns a large number of processes calling out to git for each operation. Most of these are redundant and could/should go away with either a redesign or a working caching scheme. This issue is more than obvious on platforms (e.g. some macOS versions) where fork/vfork are not as fast as one would expect. I like the paradigm behind magit,…

Meaning, it's only really slow on macOS.

Spawning processes on macOS is annoyingly slow :( I think the Linux kernel developers have put a lot more time into making sure forks complete much more quickly.

Re: Bringing GNU Emacs to native code [video]

#50

Post by metroholografix »

tptacek wrote: post #45
metroholografix wrote: post #40

Earlier quoted context omitted.

This issue has been open since 2017 and it's not panacea since it comes with its own -substantial- tradeoffs which is why as far as I know, magit is not "switching to libgit2" but planning to offer libgit2 as an additional option. Also for such an important feature, rather than going with FFI, it would be much better if Emacs linked with libgit2 (similarly to the improved JSON support in 27). That way the core Emacs…

Why do I want the Emacs team reviewing libgit2 or Magit?

They would be reviewing the C interface to libgit2, not Magit itself, since -you know this- C code written either to work through FFI or as part of Emacs can potentially corrupt memory and destabilize Emacs in serious ways. Code written in Emacs Lisp, even low quality code, does not generally suffer from these issues.

So yes, I'd much prefer C code that Daniel Colascione / John Wiegley / Eli Zaretskii / Stefan / Paul .. have reviewed over newly-written FFI code that hasn't been through that thresher. Everyone that jumped on the emacs-libvterm train early knows what I mean.

I keep Emacs running for months at a time and it's the foundation of pretty much everything I do on a computer. Other than the OS, it generally is the most stable, continuously running, continuously stressed piece of software that I have ever used.

Post reply on HN