Re: Emacs Lisp JIT Compiler

[Tom Tromey]

Paul> Are you're saying you'd rather have predictably bad performance, than 
Paul> have an application that sometimes has the bad performance in some 
Paul> situations, and 3x better performance in other situations?

I am not sure I agree with this logic; to me it sounds like a sort of
reductio ad absurdum of what Daniel said.  But what he said makes sense,
and it's an issue with the JIT idea.

That said I don't think it is a very important issue, I think primarily
because interested users can port the JIT as needed.

Eli> I agree with Daniel here: having vastly different performance due to
Eli> factors more or less out of end-user's control is bad for UX.

Eli> That doesn't mean we want to have predictably bad performance, but it
Eli> does mean that we should choose our JIT library so that it doesn't
Eli> suffer from such issues.

There is no JIT library that supports everything.  GCC targets
everything but I think (based on looking through bugzilla) doesn't
support all hosts; and also as Daniel points out, requires binutils at
runtime.  libjit has been ported to some targets but not all (for
example, it wouldn't support the Lemote Yeeloong that RMS used to use,
since it has a MIPS chip).

So, if this is the idea, then I fear Emacs will never have a JIT.

Now, one thing that is portable is compiling Emacs Lisp code to C.  For
example, it would be easy to compile all the bytecode that is dumped
into Emacs.  The drawback is that this is just a fraction of what users
use; and would probably not show major benefits.  But, maybe it would
help some.  And, it would certainly allow some existing C code (looking
at you, widget-put) to be moved to Lisp, which seems worthwhile to me.

Tom