[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why is Elisp slow?
From: |
조성빈 |
Subject: |
Re: Why is Elisp slow? |
Date: |
Tue, 7 May 2019 03:18:04 +0900 |
> 2019. 5. 7. 오전 3:08, Stefan Monnier <monnier@iro.umontreal.ca> 작성:
>
>> I’m curious: How likely is this to happen?
>
> As long as noone works on it, I'd say 0% likelihood.
>
>> I can confirm that SBCL works great on at least these platforms:
>> * Arch Linux(GNU userspace) on AMD64 (my friend’s confirmations)
>> * macOS(Darwin) on AMD64 (I’m currently using macOS)
>> * Windows 10 on AMD64 (my another friend’s confirmations)
>> * Raspbian(GNU userspace) on ARM (at least when using SBCL about a year
>> before…)
>
> [ 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?̊̈
I’m pretty sure SBCL’s platform-specific code is self-contained.
>>> Of course, Guile has the advantage that someone has already spent a fair
>>> bit of time implementing support for Elisp, whereas for CLISP and SBCL
>>> that would be extra work (Elisp is close to a subset of CL but not
>>> quite).
>> Would that extra work outweigh than implementing Guile’s language
>> integration features?
>
> No idea.
>
>> May I ask what part of elisp makes implementing in CL hard?
>
> Haven't thought too much about it, so I don't even know if it would be
> hard (the elisp.lisp implementation I mentioned recently shows that
> large parts can be done easily enough).
> The obvious issue is buffer-local and terminal-local variables.
>
>>> Another approach would be to implement an Elisp-to-JS compiler and
>>> then use one of the heavily-optimized JIT-compilers for JS.
>>> Compiling Elisp to JS should be much easier than compiling to
>>> native code.
>>
>> If possible, this would be more than great as we would be able to use the
>> *big* number of JS packages in npm registry out there.
>
> Note that compiling to JS doesn't *directly* let you access random JS
> data-structures and functions any more than implementing Elisp in C lets
> you access random C functions and data-structures.
> [ language-interoperation, again. ]
Ah, I was saying libraries in general; libraries like immutable.js or left-pad
:-)
>
> Stefan
- Re: Why is Elisp slow?, (continued)
- Re: Why is Elisp slow?, Ergus, 2019/05/06
- Re: Why is Elisp slow?, Stefan Monnier, 2019/05/06
- Re: Why is Elisp slow?, Ergus, 2019/05/06
- Re: Why is Elisp slow?, Stefan Monnier, 2019/05/06
- Re: Why is Elisp slow?, 조성빈, 2019/05/06
- Re: Why is Elisp slow?, Stefan Monnier, 2019/05/06
- Re: Why is Elisp slow?,
조성빈 <=
- Re: Why is Elisp slow?, Stefan Monnier, 2019/05/06
- Re: Why is Elisp slow?, Ergus, 2019/05/06
- Re: Why is Elisp slow?, 조성빈, 2019/05/06
- Re: Why is Elisp slow?, Jean-Christophe Helary, 2019/05/06
- Re: Why is Elisp slow?, Ergus, 2019/05/06
- Re: Why is Elisp slow?, Ergus, 2019/05/06
- Re: Why is Elisp slow?, Ergus, 2019/05/07
- Re: Why is Elisp slow?, 조성빈, 2019/05/07
- Re: Why is Elisp slow?, Ergus, 2019/05/07
- Re: Why is Elisp slow?, Stefan Monnier, 2019/05/07