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

81–90 of 138 posts

Re: Bringing GNU Emacs to Native Code (2020)

#81

Post by db48x »

zelphirkalt wrote: post #70
db48x wrote: post #52

Earlier quoted context omitted.

A lot of this is down to configuration. For example, you say “Emacs TRAMP uses one ssh connection per command”, but that’s only true if you’re not using the ControlMaster SSH option. Add this to your ~/.ssh/config file: ControlMaster auto ControlPersist yes ControlPath ~/.ssh/control/%C Then run mkdir -p ~/.ssh/control/, if you haven’t already. Why this isn’t the default I don’t know, but once configured correctly yo…

> Why this isn’t the default I don’t know, [...] I searched a little and found the following blog, which claims, that there are issues with it, when you do heavy data transfers, for example via many rsyncs at the same time: https://www.anchor.com.au/blog/2010/02/ssh-controlmaster-the... I did not test it myself. This would seem like an appropriate reason to not make it the default.

I suppose that’s a good point. With multiple large simultaneous flows, multiple TCP connections probably will be better, unless SSH goes to all of the trouble to reimplement all of TCP’s nicer features. And at that point you should just be using a real VPN anyway.

I wonder if ssh shouldn’t have a sensible default like ~/.ssh/control/%C for ControlPath, so that you could just turn on ControlMaster and have it just work. Then TRAMP could set the ControlMaster option on the command line when it runs ssh. At least then people wouldn’t have to mess with their SSH config, and they wouldn’t have to consider whether it will break something else.

Re: Bringing GNU Emacs to Native Code (2020)

#82

Post by [deleted] »

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…

[deleted]

Re: Bringing GNU Emacs to Native Code (2020)

#83

Post by vifon »

db48x wrote: post #52
volta83 wrote: post #38

Earlier quoted context omitted.

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…

A lot of this is down to configuration. For example, you say “Emacs TRAMP uses one ssh connection per command”, but that’s only true if you’re not using the ControlMaster SSH option. Add this to your ~/.ssh/config file: ControlMaster auto ControlPersist yes ControlPath ~/.ssh/control/%C Then run mkdir -p ~/.ssh/control/, if you haven’t already. Why this isn’t the default I don’t know, but once configured correctly yo…

> Why this isn’t the default I don’t know (…)

It is, it has been for a while. Check the TRAMP FAQ for details when it is being used automatically (grep for "ControlMaster"): https://www.gnu.org/software/emacs/manual/html_node/tramp/Fr...

Re: Bringing GNU Emacs to Native Code (2020)

#85

Post by ByteJockey »

lasagnaphil wrote: post #57
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.

It’s quite strange that the reputation for Emacs being slow hasn’t changed in decades even though hardware has advanced significantly...

Wirth's law: Software gets slower faster than hardware gets faster.

Re: Bringing GNU Emacs to Native Code (2020)

#86

Post by sanxiyn »

wyuenho wrote: post #49
rurban wrote: post #45

Earlier quoted context omitted.

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.

That's a MacPorts problem. Debian has libgccjit0 package for example. In due time, MacPorts will also package gccjit.

Re: Bringing GNU Emacs to Native Code (2020)

#87

Post by da39a3ee »

ashton314 wrote: post #4
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.

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…

  brew install emacs-plus@28 --with-native-comp
might be a more standard "easy" approach on MacOS.

Re: Bringing GNU Emacs to Native Code (2020)

#88

Post by brokenkebab »

cjohansson wrote: post #51
volta83 wrote: post #38

Earlier quoted context omitted.

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…

I agree about this issue, maybe in the distant future this could be fixed as well but where will VSCode be at that stage? Probably even more miles ahead, due to MS funding. When there is good async support in Emacs a lot of packages would need to be rewritten. However I prefer Emacs anyday over VSCode, I am very productive in Emacs because I'm used to doing almost everything in it

I don't think VSCode is ahead of Emacs on some objective scale. I tried to re-create my Emacs configuration with it and found it impossible. Also VSC appeared to be notably slower when tuned closer to my needs. At the end of the day there are always users who delighted by innumerable choices of configuration possibilities, and those who believe it's unnecessary cognitive load. Emacs being DIY kit appeals to the former, while VSC is built like a browser with rich plugin system, it's in between but closer to the latter. I'm sure VSC does and will have larger audience, but only better Emacs can unseat Emacs on its side of the spectrum.

Btw the effects of MS funding can be overvalued - e.g. MsTeams is among the worst IMs in the existence.

Re: Bringing GNU Emacs to Native Code (2020)

#89

Post by rurban »

wyuenho wrote: post #49
rurban wrote: post #45

Earlier quoted context omitted.

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.

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

Re: Bringing GNU Emacs to Native Code (2020)

#90

Post by riffraff »

wyuenho wrote: post #49
rurban wrote: post #45

Earlier quoted context omitted.

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.

I think you want to do

    port install emacs-devel +nativecomp
or

    port install emacs-app-devel +nativecomp
Post reply on HN