Re: Is Elisp really that slow?

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I have on my to-do list for this year to grab Tromey's JIT branch and
>> migrate it to LLVM and see what the optimization passes can squeeze,
>> possibly with some simple static analysis and, if I'm in the mood, type
>> annotations on Elisp code.
>
> Elisp's current implementation is sufficiently naive that it should be
> "easy" to make it significantly faster at least on some problems.

I'm not interested on making Elisp 30% faster. I want something that can
replace C for most purposes.

> This said, it's also easy to overlook the fact that in most
> circumstances time is spent running within functions implemented in
> C and no amount of clever compilation will help

Exactly. Elisp acts as glue code for the C base. This plus the fact that
many elisp primitives reduce to calls to C functions explains the
observed lack of impact of the JIT.

>(and clever compilation
> can easily end up counterproductive because we spend a lot of resources
> (heap space, CPU time, you name it) trying to optimize code that's
> largely irrelevant, so the end result is slower startup and no speedup,
> or worse).

Agreed.

> If you want to do a JIT thingy that speeds up Elisp "in general" then
> you need to make sure it does a good job eliminating redundant type
> checks and things like that.  You'll probably easily get good speed ups
> for the usual tight loops this way.  I encourage people to try something
> like basic block versioning for that.
>
> But I'm not sure such a "faster Elisp" will make a big difference to the
> kind of code one can write in Elisp.  More specifically, I think it'll
> take a lot of effort for a JIT to be good enough that we can implement
> the json printer/parser in Elisp instead of C.
>
> So another alternative is to make it possible to write "Elisp-ish" code
> that's specifically tailored for compilation to efficient code and
> that's specifically marked as such.  This has 2 very significant
> advantages:
> - the compiler can take its time because it's only applied to those
>   specific cases where we (presumably) know it's worthwhile.  We may
>   even run the compiler ahead of time rather than in a JIT fashion so it
>   doesn't impact startup.
> - the compiler doesn't need to accept all Elisp code and reproduce all
>   its intricate details faithfully.  It can even signal errors and burp
>   on some constructs that it doesn't want to support.
> Then again, maybe this "Elisp-ish" could be fairly far removed
> from Elisp.  E.g. it could even be plain old C (tho something in
> between is likely more interesting).

I've been advocating this Elisp-ish C for a long time. Even on your
stint as maintainer I offered my implementation of my own C-with-sexps
language.

I'm interested on islotating certain parts of Elisp, add some stuff to
help the optimizers and feed it to LLVM. Ideally, an Elisp hacker
working within those limits could implement some cpu-intensive code that
would perform similar to C with minimal retraining. At the same time,
the language must retain enough expressiveness to bring significant
advantages on development over C. defmacro is a must.