This is fantastic. I’ve been so impressed, as a user, by native-comp; but also to see so much work and dedication by a non-BDFL in overhauling such a long-running, and such a critical codebase—it speaks very highly of Andrea and the team that has been working with him.
This is awesome news. I’ve been using it as my daily driver since the end of 2019 and had no complaints. I don’t have any formal comparisons, but informally have found that Emacs just feels a smoother and more responsive with it. Not hugely so – it’s a not a 2x. But it’s enough to feel subtly better. Stability-wise, it’s also seemed to be about as good as mainline Emacs (i.e., very).
The one real tricky aspect to getting it working was that I ended up first having to make and install a custom build of GCC that included libgccjit before I could build Emacs with this branch. I expect that distros will make it easier to install once this lands, however.
Personally, I haven’t noticed any performance difference (or any difference, really) with the ‘native-comp’ branch, but I like that they’re modernizing and updating the internals.
Mostly the same here. I guess how much of a difference it makes depends on how you use Emacs, and I just don’t have that many computationally intensive tasks. The main bottle-neck are probably still IO with the disk or the network.
I’ve been using it as my daily driver since the end of 2019 and had no complaints.
Same, except I could complain about libgccjit’s compile time.. Normal operations certainly feel a lot snappier and it makes Emacs a lot more pleasant to use. But it doesn’t fix things like Emacs choking on long lines, big xml/json files, etc. so don’t expect that.
I think this is because it’s not really being used as a JIT in the sense that runtimes like v8 or the JVM mean by a JIT (opportunistic compilation of hot functions or code paths, often done in the background). If I understand it correctly, libgccjit is just a nice way to call the full GCC compiler in an incremental fashion, and have it compile to memory instead of disk. And the way Emacs native-comp is using it is to compile entire modules as they’re loaded. So it’s more like on-demand calling out to a full AOT compiler. Still nice, but a different way of integrating a native-code compiler, despite JIT being in the name.
I already use feature/native-comp branch from ~ Nov 2019, and compile the newest revision regularly. I have no issue with it, my config just plugged in well.
I can’t say how much “faster”, because I don’t do any benchmark.
This is fantastic. I’ve been so impressed, as a user, by native-comp; but also to see so much work and dedication by a non-BDFL in overhauling such a long-running, and such a critical codebase—it speaks very highly of Andrea and the team that has been working with him.
This is awesome news. I’ve been using it as my daily driver since the end of 2019 and had no complaints. I don’t have any formal comparisons, but informally have found that Emacs just feels a smoother and more responsive with it. Not hugely so – it’s a not a 2x. But it’s enough to feel subtly better. Stability-wise, it’s also seemed to be about as good as mainline Emacs (i.e., very).
The one real tricky aspect to getting it working was that I ended up first having to make and install a custom build of GCC that included libgccjit before I could build Emacs with this branch. I expect that distros will make it easier to install once this lands, however.
FWIW, libgccjit is already in Debian testing.
Personally, I haven’t noticed any performance difference (or any difference, really) with the ‘native-comp’ branch, but I like that they’re modernizing and updating the internals.
Mostly the same here. I guess how much of a difference it makes depends on how you use Emacs, and I just don’t have that many computationally intensive tasks. The main bottle-neck are probably still IO with the disk or the network.
Same, except I could complain about libgccjit’s compile time.. Normal operations certainly feel a lot snappier and it makes Emacs a lot more pleasant to use. But it doesn’t fix things like Emacs choking on long lines, big xml/json files, etc. so don’t expect that.
I think this is because it’s not really being used as a JIT in the sense that runtimes like v8 or the JVM mean by a JIT (opportunistic compilation of hot functions or code paths, often done in the background). If I understand it correctly, libgccjit is just a nice way to call the full GCC compiler in an incremental fashion, and have it compile to memory instead of disk. And the way Emacs
native-compis using it is to compile entire modules as they’re loaded. So it’s more like on-demand calling out to a full AOT compiler. Still nice, but a different way of integrating a native-code compiler, despite JIT being in the name.I already use
feature/native-compbranch from ~ Nov 2019, and compile the newest revision regularly. I have no issue with it, my config just plugged in well. I can’t say how much “faster”, because I don’t do any benchmark.Thank you so much, Andrea Corallo.