[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is Elisp really that slow?
From: |
Stefan Monnier |
Subject: |
Re: Is Elisp really that slow? |
Date: |
Sun, 12 May 2019 17:18:27 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
> 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.
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 (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).
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).
Stefan
- Re: Is Elisp really that slow? (was: Why is Elisp slow?), (continued)
- Re: Is Elisp really that slow? (was: Why is Elisp slow?), Emanuel Berg, 2019/05/12
- Re: Is Elisp really that slow? (was: Why is Elisp slow?), 조성빈, 2019/05/12
- Re: Is Elisp really that slow? (was: Why is Elisp slow?), Eli Zaretskii, 2019/05/12
- Re: Is Elisp really that slow?, Óscar Fuentes, 2019/05/12
- Re: Is Elisp really that slow?, Eli Zaretskii, 2019/05/12
- Re: Is Elisp really that slow?, Óscar Fuentes, 2019/05/12
- Re: Is Elisp really that slow?, Eli Zaretskii, 2019/05/12
- Re: Is Elisp really that slow?, Óscar Fuentes, 2019/05/12
- Re: Is Elisp really that slow?, Eli Zaretskii, 2019/05/12
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/12
- Re: Is Elisp really that slow?,
Stefan Monnier <=
- Re: Is Elisp really that slow?, Óscar Fuentes, 2019/05/12
- Re: Is Elisp really that slow?, Stefan Monnier, 2019/05/14
- Re: Is Elisp really that slow?, Óscar Fuentes, 2019/05/14
- Re: Is Elisp really that slow?, Samuel Wales, 2019/05/12
- Re: Is Elisp really that slow?, Stefan Monnier, 2019/05/13
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/13
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/13
- Re: Is Elisp really that slow?, tomas, 2019/05/14
- Re: Is Elisp really that slow?, Emanuel Berg, 2019/05/14
- Re: Is Elisp really that slow?, tomas, 2019/05/14