The Emacs-28 release branch has been created(mail.gnu.org)
mail.gnu.org
The Emacs-28 release branch has been created
https://mail.gnu.org/archive/html/emacs-devel/2021-09/msg02290.html
9 comments
Finally, my patch written and upstreamed in 2020 is going to see the light of the day!
Emacs is just the most amazing software ever. Even more important and influential than Linux.
woooo, native comp!
It's fantastic! If you are on a mac you can try it right now with emacs-plus[1]. Emacs plus even works natively with apple m1. Doom[2] with CIDER[3] is such an incredible dev experience and I've only recently started using clojure. Native comp makea everything so snappy.
[1]https://github.com/d12frosted/homebrew-emacs-plus
[2]https://github.com/hlissner/doom-emacs
[3]https://github.com/clojure-emacs/cider
[1]https://github.com/d12frosted/homebrew-emacs-plus
[2]https://github.com/hlissner/doom-emacs
[3]https://github.com/clojure-emacs/cider
I'm torn. I do feel it makes improvements. But I also add "-O3" to my compilation. And I also feel that makes things faster. I add "-march=native" on my Linux box. Again, feels faster.
What worries me, is that most of the feeling is just placebo. I know native is faster, but by how much? Are there any good benchmarks for measuring emacs speed?
What worries me, is that most of the feeling is just placebo. I know native is faster, but by how much? Are there any good benchmarks for measuring emacs speed?
If you load a bunch of packages at startup that take several seconds to load that is as good a benchmark as any. I have this at the end of my init.el:
(run-with-idle-timer
3 nil
(lambda ()
(let ((inhibit-message t))
(message "Emacs ready in %s with %d garbage collections."
(format "%.2f seconds"
(float-time
(time-subtract after-init-time before-init-time)))
gcs-done))))My startup had always been under a second. On a Mac, the command to get the path right is the longest pole. Remains so in native.
That said, I'll play with it some. Still looking for a broader benchmark, though.
Edit: Looks like I lied. Startup is about 2 seconds, but is mainly dominated by a network hit to refresh packages. (So, slower if I'm on a bad network... I should fix that.) Your script, though, is odd, as I can get to the Messages buffer and wait a second before I see that message show up. (Also, you can just eval (emacs-init-time))
That said, I'll play with it some. Still looking for a broader benchmark, though.
Edit: Looks like I lied. Startup is about 2 seconds, but is mainly dominated by a network hit to refresh packages. (So, slower if I'm on a bad network... I should fix that.) Your script, though, is odd, as I can get to the Messages buffer and wait a second before I see that message show up. (Also, you can just eval (emacs-init-time))
I'm sure I got this code from someone else, was going to replace it with (emacs-init-time) myself but I suppose it's nice to only have the first two numerals after the decimal point which this code does and (emacs-init-time) doesn't.
Funny, coming back to this, if I recompile without native compilation and any other flags, I get faster startups. By upwards of 1 second. (So, from almost 2 seconds to almost 1 second.)
An emacs -q startup is roughly the same. And I maintain that many things feel snappier with the optimization flags.
An emacs -q startup is roughly the same. And I maintain that many things feel snappier with the optimization flags.
Apropos of the path: have you tried setting your path in, say, `.zshenv`? When I started using that, I was able to shave off a significant amount of time because Emacs didn't have to fire up a full interactive shell to grab the env vars.
This is only on a Mac, right? I'll look into it, not a problem on my other machine.
IME the only thing -march=native does is it makes it impossible to boot your system on an older microarchitecture (which is trivial with Linux otherwise — I really don't understand those who bring their bad Windows habits and do a reinstall when moving between systems).
I mean, it would do that. But, I also have never just moved the hard drive between machines. I've only owned two machines in the last decade. So, not even something I have had a lot of opportunity to do.
Back to the point, though, I'm assuming that libc dynamically does most of the optimizations that native enables?
Back to the point, though, I'm assuming that libc dynamically does most of the optimizations that native enables?
I second emacs-plus. It's been a very pleasant experience on my new M1, especially relative to the default homebrew version which I could not keep working for more than 10 minutes.
Native comp is great. Most of the speed ups are modest, but it's really noticeable in some really slow operations.
For example, calculating org-table summaries in a very large org file I have (way too large, but I'm too lazy to archive) used to take over 5 minutes. Since I enabled native_comp it completes in under a minute.
For example, calculating org-table summaries in a very large org file I have (way too large, but I'm too lazy to archive) used to take over 5 minutes. Since I enabled native_comp it completes in under a minute.
What actually is native compilation? Anyone mind explaining?
Emacs lisp can be compiled into bytecode (*.elc files) for faster execution.
Native compilation takes bytecode and compiles (all while doing some smart things like type and value propagation) it into machine code utilising libgccjit.
This results in some very nice speed gains.
The author described the project in his blog here: https://akrl.sdf.org/gccemacs.html
Native compilation takes bytecode and compiles (all while doing some smart things like type and value propagation) it into machine code utilising libgccjit.
This results in some very nice speed gains.
The author described the project in his blog here: https://akrl.sdf.org/gccemacs.html
From what I can tell from https://www.emacswiki.org/emacs/GccEmacs - enabling a JIT for Emacs Lisp
It's not a JIT compiler, really. Just one more step (a big one, admittedly) for the existing bytecode compiler.
Aot in a way right ?
Yes, some kind of lazy ahead-of-time compilation.
By default the native compiler kicks in as soon as Emacs finds a bytecompiled file without a machine code equivalent. The resulting machine code is cached then for future use so this only happens once per a single *.elc file.
At least this is what i remember from the last time I checked the code :-)
By default the native compiler kicks in as soon as Emacs finds a bytecompiled file without a machine code equivalent. The resulting machine code is cached then for future use so this only happens once per a single *.elc file.
At least this is what i remember from the last time I checked the code :-)
Compiling to machine code
I like native comp (and major kudos to the devs) but my poor ThinkPad x201 smokes after large ELC cache update.
Detailed changelog here: https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS.2...
Emacs is a perfect GNU propagator. To be able to use its full power you need an entire ecosystem of GNU tools. For that reason you can only get its full power by abandoning your Windows or Apple OS and converting to GNU/Linux and if you use Emacs you will do that sooner or later
Feature request. Let Emacs spawn background Emacs subprocess to do batch jobs like Org Mode publish on buffer-save without spinning hour-glass freezing out the emacs-user from interactive editing.
Hum async-start from async.el seems exactly what you want?
Standard emacs also has make-process and friends.
edit: of course emacs won't be able to automatically make all time consuming tasks asynchronous. Each package would need to support async processing as required.
Standard emacs also has make-process and friends.
edit: of course emacs won't be able to automatically make all time consuming tasks asynchronous. Each package would need to support async processing as required.
Anyone know if adding tree-sitter to core will be part of version 28?
Tree-sitter integration (through the fast C layer) is in its early stages, I wouldn't expect it until Emacs 29 or later.
There is a lisp-based tree sitter package that works for now, but there are no plans to add it to the core.
There is a lisp-based tree sitter package that works for now, but there are no plans to add it to the core.
They grow up so fast...
So. It has come to this.