Bringing GNU Emacs to Native Code (2020)
1–10 of 138 posts
Re: Bringing GNU Emacs to Native Code (2020)
#2The 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.
Re: Bringing GNU Emacs to Native Code (2020)
#3[deleted]
Re: Bringing GNU Emacs to Native Code (2020)
#4The 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.
I tried this on macOS a few months ago and it was pretty rocky just getting the thing compiled. I tried again last night and it pretty much Just Worked(tm) thanks to this[1] project.
Note: this was on an Intel mac; anyone with an M1 tried this yet?
I did run into some problems with some newer packages on the GNU ELPA. (Specifically consult, marginalia, and vertico by github.com/minad) Straight.el complained about not being able to find the packages. Any suggestions on what I might try to fix this?
Re: Bringing GNU Emacs to Native Code (2020)
#5The 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.
I tried this on macOS a few months ago and it was pretty rocky just getting the thing compiled. I tried again last night and it pretty much Just Worked(tm) thanks to this[1] project. Note: this was on an Intel mac; anyone with an M1 tried this yet? I did run into some problems with some newer packages on the GNU ELPA. (Specifically consult, marginalia, and vertico by github.com/minad) Straight.el complained about not…
[deleted]
Re: Bringing GNU Emacs to Native Code (2020)
#6I 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 capabilities.
Re: Bringing GNU Emacs to Native Code (2020)
#7I 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…
My impression is that the major bottleneck is the redisplay loop.
Re: Bringing GNU Emacs to Native Code (2020)
#8The 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.
Is the speedup during editing or does it also improve startup time?
Re: Bringing GNU Emacs to Native Code (2020)
#9Slime didn't work for me in this version of Emacs. (Slime is the Common Lisp IDE for Emacs). I don't remember the details but I think Slime was getting confused about .el vs .elc files and assuming there was no third option, but now there is.
Re: Bringing GNU Emacs to Native Code (2020)
#10Slime didn't work for me in this version of Emacs. (Slime is the Common Lisp IDE for Emacs). I don't remember the details but I think Slime was getting confused about .el vs .elc files and assuming there was no third option, but now there is.
Interesting, I've been using Slime with nativecomp for a long time.