Re: Emacs Lisp JIT Compiler

[Daniel Colascione]

Thanks for doing this work.

On 12/05/2016 10:16 AM, Burton Samograd wrote:
> Hello,
>
> I’ve published my Emacs Lisp JIT compiler for comments and review:
>
>     https://github.com/burtonsamograd/emacs-jit
>
> The JIT compiler implements a strategy of turning the byte code
> execution loop into a series of function calls, moving the overhead of
> the loop into the CPU execution unit.  I call this ‘compiling down the
> spine’ of the byte code vector.  No other changes have been done to the
> byte code instructions other than to map them to the new execution strategy.
>
> This is work in progress and about ~90% complete and was done about 4
> years ago, so it’s quite a bit off of HEAD right now.  It ‘works’ to the
> point of being able to JIT compile and run my included ray-tracer with a
> 25% speed improvement.  Enabling full JIT during compilation shows bugs
> and will fail; I haven’t been able to track down the cause of these
> failures yet.

Let's benchmark it after making sure it's correct.

> By default, this build will provide the Lisp function 'jit-compile’
> which takes a lambda expression or a symbol.
>
> A new byte code instruction has been added Bjitcall.  When a function is
> JIT compiled, it’s code vector is replaced by the single Bjitcall
> instruction followed by the JIT compiled code block.

I'm hesitant to call this work a "JIT compiler", since it's not doing 
any "compilation" --- CFG construction, register allocation, 
machine-code generation. we're still executing the same bits of the 
interpreter code ---- just reaching them more efficiency. (It's a step 
in that direction though.) Since each function pointer (four or eight 
bytes) is much larger than the corresponding bytecode instruction, for 
cache efficiency reasons, I'd apply this optimization only to hot functions.

Four years ago, GCC's JIT API was unavailable. I suggest taking a close 
look at it. It will deliver far greater speedups to computation than the 
techniques in this work can, and it's much lower-maintenance to boot.

BTW: we don't use C99 dynamic arrays in Emacs.