
Emacs Lisp JIT Compiler - unhammer
https://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00393.html
======
fusiongyro
I hate to be "that guy," but what happened to the Guile-Emacs project? Guile
performs way better than Elisp too, but (perhaps more importantly) raises the
possibility of writing configuration and extensions in Lua and Scheme.

~~~
rauhl
IMHO switching to Guile from C is moving in the wrong direction: rather than
going from a poor-but-performant systems programming language like C to a
pedagogic language like Scheme, it’d be a better idea to move to an rich-and-
performant language meant for industrial systems programming like Common Lisp.
Scheme’s a pretty little language, but it’s not meant for building large
applications. Indeed, elisp’s weaknesses are IMHO mainly where it’s most akin
to Scheme (e.g. its flat namespace).

I also think it’d be a bad idea to make it too easy to write emacs extensions
in anything but a Lisp, because that would fragment the ecosystem. If we’re
going to replace elisp, it should be with a better Lisp, not with a lesser
language (e.g. Lua, Python, Ruby … whatever).

The great thing about a JIT is that we get a speedup without changing the
actual implementation language or fragmenting the ecosystem.

~~~
fusiongyro
The idea was to replace Emacs's embedded Elisp interpreter with Guile's, not
to rewrite Emacs in Guile Scheme.

~~~
eadmund
Why not just replace Emacs's embedded elisp interpreter with one written in
Common Lisp? CLOCC has a basic elisp interpreter already:
[https://sourceforge.net/p/clocc/hg/ci/default/tree/src/cllib...](https://sourceforge.net/p/clocc/hg/ci/default/tree/src/cllib/elisp.lisp)

Take that, put a little work into it and one could presumably replace the C
core of Emacs with Common Lisp.

~~~
melling
Stallman hates Common Lisp.

[https://www.gnu.org/gnu/rms-lisp.en.html](https://www.gnu.org/gnu/rms-
lisp.en.html)

~~~
mark_l_watson
Thanks, that was a fun read. BTW, I don’t think Richard totally dislikes
Common Lisp: years ago I got an email from him about releasing my ancient
Springer-Verlag Common Lisp book under the FSF documentation license.
Unfortunately I couldn’t do it because I didn’t have the manuscript files.

~~~
avar
If you own the copyright to the text couldn't you make it known that if
someone were to OCR it, clean up the formatting, and publish it that the
result could be freely distributed?

~~~
jacobush
I guess in a fair and honest world, yes because it's legal?

But in our actual world, it's also legal but publishers may play dirty and
somehow claim rights because you published something based on their edition?

Just thinking out loud.

------
gopalv
That's quite a blast from the past.

Good on Aleksey for picking it up and modernizing libjit to this point.

And for everyone who thinks of LLVM in this context, here's a thread with some
"primary sources" [1].

[1] - [http://lists.gnu.org/archive/html/dotgnu-
libjit/2004-05/msg0...](http://lists.gnu.org/archive/html/dotgnu-
libjit/2004-05/msg00012.html)

~~~
earenndil
AFAIK, llvm jit is incredibly slow, to the point that certain emulators that
have used it have had to drop it for performance's sake.

~~~
fasquoika
IIRC LLVM relatively recently did a major overhaul of the JIT API, including
better support for lazy compilation. That might improve compilation speed
drastically

------
dangirsh
Don't miss the later comments by Richard Stallman (creator of Emacs), and
Tom's reply:

    
    
      Richard> I don't think a 3% speedup is worth those drawbacks.  
      Richard> Or even a 10% speedup. 
      Richard> A really big speedup would justify the costs.
      
      Tom> It is 3x, not 3%.
    

Mic drop.

~~~
chubot
More context:

 _In some simple benchmarks, it is about 3x faster than the bytecode
interpreter._

I'm always skeptical of statements of these, because workloads vary so much.

JITs seem to do well for numerical benchmarks, e.g. summing a list of numbers
or the mandelbrot fractal.

They seem to do worse with string-based workloads, because the bottleneck is
in memory allocations, and I have yet to see a JIT that does anything about
that (i.e. analyzing code to reduce allocations).

I imagine that ELisp is used mostly for string workloads and not numeric
workloads. So I won't be surprised if the 3x number doesn't hold up. I'm
interested in hearing more details and happy be to be corrected.

~~~
PeCaN
>I have yet to see a JIT that does anything about that (i.e. analyzing code to
reduce allocations).

Most JITs do this. LuaJIT does allocation sinking of tables, strings, and even
C-FFI structs. HotSpot does escape analysis of everything. IIRC Graal can even
do partial escape analysis (allocate the object on the stack and then copy it
to the heap if it escapes on one code path). I imagine the major JavaScript
engines are similar. It's a well-known performance optimization.

~~~
mamcx
Any source in how escape analysis is implemented? Is only usefull for JIT or
also for "normal" bytecode interpreter?

~~~
chrisseaton
Traditional escape analysis uses algorithms like _equi-escape sets_.

[https://www.usenix.org/legacy/events/vee05/full_papers/p111-...](https://www.usenix.org/legacy/events/vee05/full_papers/p111-kotzmann.pdf)

------
avdicius
The development of libjit almost halted a while back. But thanks to the last
GSoC it is set to receive a major update soon:
[https://github.com/ademakov/libjit/pull/14](https://github.com/ademakov/libjit/pull/14)

~~~
vkazanov
Is it about the new register allocator? How good is it?

~~~
avdicius
Yes, initial benchmark results:
[https://github.com/M4GNV5/GSoC2018](https://github.com/M4GNV5/GSoC2018)

------
davidw
> From: Tom Tromey

Of course it is. That guy's an amazing wizard.

------
zokier
The authors blog has some extra details (see also the comments)

[https://tromey.com/blog/?p=982](https://tromey.com/blog/?p=982)

------
vemv
Tangentially related:

applying some commonly-recommended optimizations, you can shave Emacs init
time to about 2 seconds, from whatever your previous init time was (7 in my
case, but I also read about 60s -> 2s improvements).

Init time alone greatly affects how a given system is perceived.

~~~
fusiongyro
What are these recommended optimizations?

~~~
dan-robertson
The extreme version is to reproduce a step from building Emacs where you
produce a binary with the libraries you want already loaded into memory. This
is like making a lisp-image except the image also includes a big C text editor

~~~
vemv
This sounds pretty neat (and something a CI server could routinely do) - has
it been done in practice?

~~~
dan-robertson
Doing this requires various security features that operating systems have
gained since the 1980s to be turned off so it’s not super advisable if you can
avoid it

------
Myrmornis
Cool! I just compiled it. How do I know whether the jit is enabled / I wonder
how to convince myself what the speedup is for different usages.

    
    
      git clone git@github.com:emacs-mirror/emacs.git
      cd emacs
      git checkout feature/libjit 
    
      # Instructions for macos from
      # https://stuff-things.net/2018/01/30/building-emacs-25-on-macos-high-sierra/
      brew install autoconf automake texinfo
      export PATH="/usr/local/opt/texinfo/bin:$PATH"
      
      make configure
      ./configure --with-ns
      make install
      
      open nextstep/Emacs.app

------
mijoharas
Absolutely love the message from stallman and the response (paraphrased below,
full quote [0]):

Richard> I don't think a 3% speedup is worth those drawbacks [ed: added
complexity]. Or even a 10% speedup. A really big speedup would justify the
costs.

Tom> It is 3x, not 3%.

[0] [https://lists.gnu.org/archive/html/emacs-
devel/2018-08/msg00...](https://lists.gnu.org/archive/html/emacs-
devel/2018-08/msg00439.html)

------
vmsp
The code is in branch feature/libjit of emacs' repo, if anyone wants to take a
look.
[http://git.savannah.gnu.org/cgit/emacs.git/tree/?h=feature/l...](http://git.savannah.gnu.org/cgit/emacs.git/tree/?h=feature/libjit)

------
jkabrg
Wouldn't it be nice if ELisp were implemented in RPython? What sort of
difficulties would this face over the JIT compiler in the link? It would have
the advantage that such an ELisp implementation would still be an interpreter
(annotated and auto-JITted). Presumably, that would keep it "simple".

------
tmalsburg2
With JIT compilation, wouldn't byte compilation become redundant? If yes, a
JIT could significantly reduce the complexity of Emacs (contrary to RMS's
comment).

~~~
gopalv
> wouldn't byte compilation become redundant?

Bitcode is still useful, even with a JIT (just like in Java) - the JIT needs
to do the heavy parsing, semantic analysis etc everytime it starts.

However, the JIT means it can execute the bitcode faster than an interpreter
can, because it can keep more intermediate steps in registers directly (like
spill to an xmm register, instead of heap) & can do a tiny bit of cpu guided
optimization (like is AES-NI available etc).

------
microcolonel
Cool to see that libjit can actually help with elisp, I've not really seen
many other uses of libjit.

------
didibus
Make my emacs faster, yes please!

------
sillysaurus3
The reason it's difficult to make elisp fast is because the language defaults
to dynamic scoping rather than lexical scoping. That means any function that
uses `let` is no longer making a tailcall. Meaning you have to restore the
value of each variable after you call whatever function would have been the
tailcall.

Stuff like that adds up. It's why Lua is so fast compared to JS, too.

~~~
tasty_freeze
This indicates that node (v8 js) is much faster than lua, contrary to what you
just said:

[https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/faster/lua-node.html)

~~~
e12e
As others have mentioned, luajit is a lot faster than lua:

[http://luajit.org/performance_x86.html](http://luajit.org/performance_x86.html)

As an aside, I see there a gitlab project for the benchmark game - but I was
surprised there doesn't appear anyone has put together an automated, open,
bring your own language/code/patches version? Maybe with some community voting
(eg: prefer idiomatic vs max speed)?

[https://salsa.debian.org/benchmarksgame-
team/benchmarksgame/...](https://salsa.debian.org/benchmarksgame-
team/benchmarksgame/blob/master/CONTRIBUTING.md)

~~~
igouy
> …but I was surprised there doesn't appear anyone has put together…

Why haven't you? That's probably why no one else has :-)

Instead be surprised that someone has continued to push the benchmarks game
along, and that people have continued to contribute programs _gratis_.

~~~
e12e
It's been on my todo-list over neat ideas for a while. I just assumed someone
would've beaten me to it by now :)

I suspect it might have to do with resources - dedicating multiple cores to
benchmarking isn't going to be easy to do for free. Might be feasible for low
cost, though.

------
ezoe
[https://lists.gnu.org/archive/html/emacs-
devel/2018-08/msg00...](https://lists.gnu.org/archive/html/emacs-
devel/2018-08/msg00437.html)

>To replace an interpreter by a JIT compiler means more oomplexity and > also
more possible problems. (For example, if there are platforms > someday that
libjit does not support.) Reading a Lisp interpreter is > very useful for
learning.

> If the plan is to add a jit and keep the Lisp interpreter as well, > we
> don't lose its advantages for study, and we can still support all > the
> platforms -- but we add complexity even more.

> I don't think a 3% speedup is worth those drawbacks. Or even a 10% >
> speedup. A really big speedup would justify the costs.

Why do they still let RMS allows to say something about technical today?

No wonder Emacs is losing the users.

~~~
fantispug
A 3% increase in speed is a miniscule improvement. Emacs has a small dedicated
group of maintainers, increasing the maintenance burden will stop other
developements (such as the recent addition of async which is a much bigger
performance issue). If emacs is losing users I would guess it is because to
make it an IDE takes more configuration, and has more issues than competing
products.

~~~
Latteland
it's 3x, 3 times, not 3%

