FS#74348 - [emacs] Enable native compilation
Attached to Project:
Arch Linux
Opened by pancho horrillo (pancho) - Monday, 04 April 2022, 15:38 GMT
Last edited by freswa (frederik) - Thursday, 07 April 2022, 21:09 GMT
Opened by pancho horrillo (pancho) - Monday, 04 April 2022, 15:38 GMT
Last edited by freswa (frederik) - Thursday, 07 April 2022, 21:09 GMT
|
|
Details
Description:
The recently released Emacs 28.1 optionally supports¹ native compilation of Lisp files. The performance benefits this feature provides are noticeable, and thus we (the emacs mob with torches ;-P) kindly request for it to be activated in the official package. For that what is needed is: - Add `libgccjit` as a dependency - Add `--with-native-compilation` to `./configure` - Add `--without-compress-install` to configure - Call² `make NATIVE_FULL_AOT=1` (instead of plain `make`) Note that the Ahead of Time compilation will make the build to take noticeably longer, but on the other hand it will be done just once, and enjoyed by millions (trillions?) of happy emacs users. To see the whole thing in action, you can check emacs28-git @ AUR³ (DISCLAIMER: I'm the packager). Thanks a lot for your effort and dedication. Happy hacking, pancho References: 1: https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-28&id=5a223c7f2ef4c31abbd46367b6ea83cd19d30aa7#n21 2: https://git.savannah.gnu.org/cgit/emacs.git/tree/ChangeLog.3?h=emacs-28&id=5a223c7f2ef4c31abbd46367b6ea83cd19d30aa7#n64683 3: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=emacs28-git |
This task depends upon
Closed by freswa (frederik)
Thursday, 07 April 2022, 21:09 GMT
Reason for closing: Implemented
Additional comments about closing: emacs{,-nativecomp}-28.1-2
Thursday, 07 April 2022, 21:09 GMT
Reason for closing: Implemented
Additional comments about closing: emacs{,-nativecomp}-28.1-2
> to configure with the '--without-compress-install' option, so that the
> installed "*.el" files are not compressed; otherwise, you will not be
> able to use JIT native compilation of the installed "*.el" files.
Would it not be preferable to enable zlib (my /usr/bin/emacs binary is linking to libz so I assume we are doing this already) so that `--without-compress-install` is unnecessary?
It would be great if the stock emacs packages are native compiled by default (AOT) but it would be good to get a site file that disables native compilation by default for user files, requiring users to opt in to the feature.
Such a conservative approach would allow us to be more aggressive with native compilation long after the community has found and fixed the majority of bugs in ELPA and MELPA packages.
> Would it not be preferable to enable zlib (my /usr/bin/emacs binary is linking to libz so I assume we are doing this already) so that `--without-compress-install` is unnecessary?
My thinking was that this would perhaps be better handled at the filesystem level, where more efficient algorithms than what zlib offers can be used, like zstandard. But I just realized that transparent compression is not available for ext4 (I use BTRFS, which can do that).
The only thing I can think of in favour of not compressing is that perhaps the load times would be higher, because of the decompression time. But we need to measure, otherwise I don't know which scenario is better. (For me, faster load beats bigger disk usage).
Comments?
A solution would be to provide two packages:
pkgname=(emacs emacs-nativecomp)
On that topic, feel free to drop the options --with-cairo and --with-harfbuzz, because they are now both enabled by default.
OTOH, regarding --native-compilation not being enabled by default, I don't think it will be anytime soon, because it requires building emacs with gcc and binutils (besides libgccjit), and emacs also supports building with clang/gold, etc. But from what I can tell, it is not considered experimental anymore.
My 2 cents.
I'd like to just +1 this request. nativecomp is indeed not a default but, given the massive gain in performance and how stable it is, I don't think it'd be in the interest of the Arch community using Emacs to leave it aside. Many users will begin installing/building Emacs from AUR. Having two packages in Extra might be a way out indeed but not sure it'd be worth the extra effort to maintain the configuration fork.
For now, I'll use an AUR alternative but would be great if a package in the official repositories could provide emacs with native compilation.
Having two different packages sounds like a good idea; though, it's true that it adds extra effort to maintain.