Re: Emacs Lisp JIT Compiler

[Tom Tromey <tom@tromey.com>]

>>>>> "Daniel" == Daniel Colascione <dancol@dancol.org> writes:

Daniel> I also strongly suspect (albeit without numbers ATM) that the standalone
Daniel> approach will yield much better performance than one which involves a trip
Daniel> through the filesystem and a compilation toolchain. A standalone system
Daniel> lets us do tiered and profile-guided compilation in a way that a big batch
Daniel> process really can't accommodate due to overheads.

True, though it's worth noting that libjit doesn't really have
optimization passes to speak of.  Also things like deoptimization seem
hard with libjit; there's no support for patching functions or on stack
replacement or whatnot.

libjit optimizations could be written.  I haven't tried, so I don't
know how hard it is in practice.

I do have an incomplete branch where I'm changing the JIT calling
convention to try to get better performance in the common case.  This
branch would also allow inlining (with a runtime check to ensure the
callee hasn't changed).

Going beyond this sort of thing (for instance Stefan sent me this very
interesting paper about basic block versioning) probably requires a
truly custom JIT from the bottom up.

Daniel> Likewise, it'd be fantastic to compile regular expressions to DFAs and
Daniel> then generate machine code for the DFAs. You can't go faster than that.

I've been meaning to experiment with this using Stefan's lex.el.
It seems to me that the bytecode compiler could open-code some common
things like (looking-at "some constant").

One "simple" way to improve regexp matching right now would be to remove
the self-modifying code and change the implementation to use token
threading, like we did for the bytecode interpreter.  Not nearly as good
as a DFA but still a step forward.  I think removing this self-modifying
stuff is also useful if we ever want to introduce first-class regexp
objects.

Tom