emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Lisp JIT Compiler


From: T.V Raman
Subject: Re: Emacs Lisp JIT Compiler
Date: Mon, 13 Aug 2018 06:50:03 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Tom Tromey <address@hidden> writes:

Will it work with adviced functions?> Hi.  I've written a JIT compiler for 
Emacs Lisp, and I'd like to check
> it in.
>
> This JIT is based on GNU libjit, like some other attempts that have come
> before it.  However, this one is somewhat faster than those, primarily
> because it does all stack manipulations at compile time, not runtime.
>
> In some simple benchmarks, it is about 3x faster than the bytecode
> interpreter.
>
> I have only tested this on x86-64.  Whether or not the JIT works on a
> given platform is primarily up to libjit.  (I suspect the JIT won't work
> on x86 with --with-wide-int; but that is something I could fix.)
>
> I currently have the JIT set up to always compile all eligible functions
> (that is, just byte-compiled, lexically-bound functions).  It's robust
> enough that, as far as I can tell, everything works fine in this mode.
> It would be possible to have it be a bit lazier, say only compile after
> 100 invocations, or something like that.
>
> Aside from the possible --with-wide-int thing, there are two bugs I know
> of.
>
> First, libjit never frees functions.  So, if a function is JIT-compiled
> and then redefined, the old JIT code will linger.  It's possible to fix
> this with a custom allocator and a libjit patch (that I sent but that
> hasn't been checked in yet).
>
> Second, I haven't gotten around to emulating the "quitcounter" behavior
> in the bytecode interpreter.  This seems straightforward.
>
>
> This version of the compiler is pretty basic.  It just compiles each
> bytecode to more or less the obvious thing.  I have some plans to make
> the calling convention a bit less expensive, and to allow for inlining.
>
> Note that this change does not involve any semantic changes to Emacs Lisp.
> Also, if libjit is unavailable, the JIT is simply disabled.
>
> Tom
>

-- 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]