Re: Why is Elisp slow?

[Ergus]

I considered that possibility.

Give a look to the files sizes inside src in Emacs sources. Only xdisp.c, for 
example, is more than 33000 lines. Projects like remacs are migrating the C 
code to rust and they have needed years and only moved small portions. Also the 
lisp compilers aren't as good optimized and mature as GCC for example. And big 
changes will make the code unfamiliar for our developers.

But we have the scoping differences with common lisp, so that will also force 
big updates in the lisp code...


On May 10, 2019 5:20:29 AM GMT+02:00, "조성빈" <pcr910303@icloud.com> wrote:
>I’m just dreaming, but what if Emacs goes the Stumpwm-way and implement
>everything in CL? There are previous efforts; We might be able to build
>on them...? 
>
>나의 iPhone에서 보냄
>
>2019. 5. 9. 오후 6:49, Ergus <spacibba@aol.com> 작성:
>
>> Hi:
>> 
>> After some mails in the SBCL mailing list and make some
>> question-reply-question there; I arrived the conclusion that SBCL is
>not
>> an alternative :( I was very wrong.
>> 
>> I'll copy-paste the main answers here just in case someone wants to
>go
>> this way in the future. Or in case someone more expert see some
>possible
>> workaround for the issues exposed here.
>> 
>> ----------------------------------------
>> 
>> Your question as stated is too open-ended for me to discern the exact
>> intent, but I think's it's something like this: there is much
>common-lisp
>> code that people run in emacs, and you'd like not to have to maintain
>a
>> common-lisp compiler as well as elisp compiler. Instead you'd like to
>> retarget the output of the SBCL compiler to produce elisp byte code
>for
>> execution.
>> It's unclear whether you'd expect this to be an out-of-process
>compiler or
>> an in-process compiler.  If in-process, then you've got larger
>problems
>> than figuring out how to call C.  SBCL is not intended to be a
>"subsystem"
>> of other lisps, nor even to allow main() to be anything other than
>its own
>> main(), though that limitation has been relaxed a bit.
>> 
>> If out-of-process, then I would imagine that SBCL would operate as a
>file
>> compiler only, and not a compiler of arbitrary forms. You need to
>figure
>> out how to treat emacs as the virtual machine which the SBCL compiler
>> targets, and a suitable interface for getting the compiled code out
>of an
>> SBCL '.fasl' file and into emacs.   The "machine code" in the '.fasl'
>file
>> would actually be emacs byte code. (I'm assuming that you plan to
>keep
>> more-or-less the same byte code execution engine)
>> 
>> I don't see why C functions are a particular problem.  SBCL uses C
>> functions all the time.  In fact it is extremely interoperable with
>C, but
>> that's really asking the wrong question imho.
>> Portability is the real question, since you brought it up. Are you
>implying
>> that SBCL's compiler should produce machine code that would run
>within
>> emacs? This is highly unlikely; I won't say impossible, but darn near
>so.
>> First of all, SBCL can produce machine code only for a tiny fraction
>of
>> the CPUs that emacs supports. Secondly, producing machine code
>assumes that
>> the entirety of the runtime (comprised of the memory layout, heap
>objects,
>> and support routines) is exactly as SBCL expects it to be - symbols
>look
>> like SBCL symbols, special variables get bound in exactly the way
>that SBCL
>> expects them to get bound.  SBCL's compiled lisp files are not a
>portable
>> abstraction like a '.o' file (or '.so' if you like) that could be
>loaded
>> into *any* other program (a C program, Java program, etc) and just
>run.
>> 
>> But as I said initially, I think you're trying to suggest that you
>would
>> produce code that is executed by the emacs lisp engine, not the CPU
>> directly.
>> So that would be essentially 1 new architecture that SBCL would have
>to
>> support, namely the emacs virtual machine.  That sounds more
>plausible and
>> there's no reason to care about the set of CPUs that we can directly
>> compile for, nor even how the existing architectures would call C
>code.
>> You'd have to invent that as part of the retargeting to the emacs vm.
>> 
>> Doug
>> 
>> ----------------------------------------
>> 
>> I believe the most viable way to use SBCL for Emacs would be to
>rethink
>> the approach: instead of a graphics engine written in C - in addition
>to
>> many Lisp functions - and Elisp used to "script" that, with SBCL you
>no
>> longer need to have much of that C code for performance reasons.
>> 
>> The entry point to this hypothetical new Emacs would be in Common
>Lisp,
>> as well as an Elisp environment that would be mostly macrology on top
>of
>> CL (to start with). After that, you could consider rewriting much of
>the
>> rendering engine into Lisp too, and leave only a tiny amount of C
>> strictly for interfacing with the operating system.
>> 
>> I know some people have discussed about turning SBCL into a shared
>> library but the amount of work would be considerable and with little
>> gain because I doubt that the SBCL maintainers are interested in
>> committing to a stable C ABI to the compiler internals - otherwise
>> embedding SBCL into a C program would be of little use except for
>maybe
>> running CL away from the main thread.
>> 
>> Stelian Ionescu
>> 
>> ----------------------------------------
>> 
>> I expect portability to be a real issue here. If you *do* want to
>rely on S=
>> BCL to generate native machine code for you, and abandon supporting
>platfor=
>> ms that SBCL doesn't, that would be OK. This would entail
>significantly mod=
>> ifying the Emacs runtime though. The SBCL compiler is married pretty
>heavil=
>> y to its runtime (mainly through the GC, which is written in C), and
>SBCL i=
>> s a small C program which simply jumps to the Lisp entry point in a
>large L=
>> isp image and stays there in its own world, with its own calling
>convention=
>> and object layour, occasionally calling back out to C for operating
>system=
>> tools and GC, which understands Lisp objects and calling conventions.
>So L=
>> isp/C interoperation works very well, but as others have stated, it
>works i=
>> n a very SBCL-specific manner. I reckon the hard part would be
>getting the =
>> C engine for Emacs to fit in the picture, hence the suggestion to
>rewrite m=
>> uch of it in Lisp.
>> But the reality is I sort of doubt that eliminating support for a
>wide vari=
>> ety of other architectures is acceptable to Emacs. Hence the
>suggestion to =
>> create an Emacs bytecode backend. This would solve the portability
>problem,=
>> at the cost of some efficiency. SBCL tries much harder than Emacs to
>produ=
>> ce good code (by utilizing high level optimizations such as
>constraint (e.g=
>> . type) propagation), however, so even then the bytecode produced by
>SBCL w=
>> ould be superior compared to what Emacs can produce now. A problem
>with thi=
>> s is that the compiler really does expect to be targeting a CPU ISA
>rather =
>> than something higher level, so you'll have to be clever to figure
>out how =
>> to set up the translation from the machine independent intermediate
>represe=
>> ntation (IR2), and Elisp bytecode.
>> Finally, another option to reap the benefits of SBCL's fastish code
>generat=
>> ion while not sacrificing portability is to figure out how to make
>Emacs a =
>> portable Common Lisp program, through use of portable libraries for
>foreign=
>> code interop, graphics, and Elisp (through macrology, most likely).
>Then i=
>> t will run on all platforms that have C compilers through other Lisp
>implem=
>> entations which do not target machine code (like ECL, CLISP, etc...)
>and us=
>> e SBCL for the platforms it supports. This approach is taken by
>StumpWM, wh=
>> ich is fairly similar to Emacs.
>> =20
>> Charles
>> 
>> ----------------------------------------
>> 
>> On Tue, May 07, 2019 at 10:22:39AM -0400, Stefan Monnier wrote:
>>>> embed ECL (Embeddable Common Lisp), which
>>>> * is significantly slower than SBCL, about 2~3x slower? but is
>still
>>>>  much faster than Elisp.
>>> 
>>> Last time this discussion came up, ECL seemed like the most
>promising
>>> option indeed, but the performance was not that impressive compared
>to
>>> Emacs.  Maybe the situation has changed?
>>> Also in terms of maintenance, it's minimal, so it wouldn't help very
>>> much on the side of manpower.
>>> 
>>> 
>>>       Stefan
>>> 
>>> 
>> 

-- 
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi 
brevedad.