Re: Why is Elisp slow?

[Ergus <spacibba@aol.com>]

Hi all:

After reading the whole SBCL manual and the internals I have some
comments maybe useful if we decide to go in that direction. (If some of
the core developers starts with this I will be very pleased to work on
that, but I am too new in emacs development to start it myself alone.)

1) + Portability does not seems to be a big issue, they already support
 our architectures (and some extra) and they are putting a lot of effort
 on that. There is work to do, but in general, they already have what we
 need from Common Lisp.

2) + They have documented how to port SBCL to new architectures, and some
of the optimizations they implement, so, if we have a compiler
specialist on board and finally our developers choose not to go for
SBCL, then maybe some of those optimization could be considered for our
Elisp compiler.

3) - There is not C binding for SBCL. To extend it, there is not a
public-documented API and their approach is wrapping the C functions
from Lisp (FFI). I wrote in their mailing list and they redirected me to
the CFFI page.

    + The only advantage (I see) in this approach is that as CFFI has
    been ported to almost all common list compilers/interpreters; if we
    go in that direction for our C code we could potentially use any of
    those and jump from one to another at configuration time. So we
    don't have this problem (of being stock with a "bad" compiler)
    anymore.

    - The overhead produced by wrapping in the high level instead of the
      low level in my experience (python, ruby, Julia) is usually much
      higher than having C bindings. 

    - Writing wrappers in lisp for all our C functions exposed to Lisp I
      think is not an option if we don't create an automatic method. So
      if no one creates a plugin for sbcl to support Elisp, I really
      doubt the feasibility of using SBCL except if many of our current
      core developers agree on that and join effort for that. Else it
      will happen as with guile.

4) + With FFI as they implemented, it will be pretty easy to interface
and call C libraries and functions without needing a C wrapper to expose
it to lisp, so maybe an important part of our C code could be
substituted with Lisp (simpler and smaller) glue code. But also we will
be allowed to use C dynamic libraries directly without all the modules
complexity. (Somehow I feel that not everyone will like that if we
comment it in the developers mailing list :p ).



On Mon, May 06, 2019 at 02:47:12PM -0400, Stefan Monnier wrote:
>>> [ IIUC of the 4 cases above, at most 2 run the same version, so we'd
>>>  need to make sure the same Emacs version can be compiled against all
>>>  of those versions.  No idea if it would impose a significant extra
>>>  burden or not, but it's something to be considered.  Also the fact
>>>  that the latest release doesn't work on all those platforms is rather
>>>  worrying.  ]
>>
>> Hmm???? I can???t understand :-(
>> Why can???t Emacs can include a specific version of SBCL???s source (e.g. as
>> a git module) and compile them all together?????
>
>Exactly because the version that can run on ARM is not the same as the
>one that can run under Windows, which is not the same as the one that
>runs under AMD64.
>
>Of course, maybe I'm confused by the table of available binaries (at
>http://sbcl.org/platform-table.html), and in reality the latest version
>works fine on all supported platforms.
>
>
>        Stefan
>
>