From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?7KGw7ISx67mI?= Newsgroups: gmane.emacs.help Subject: Re: Why is Elisp slow? Date: Fri, 10 May 2019 12:20:29 +0900 Message-ID: <9C8C6E45-4E41-489C-AE75-80B52569586E@icloud.com> References: <84F2860D-523D-4F30-BD52-D6A915416167@icloud.com> <20190507104945.gfdrftaeztrzbkt6@Ergus> <44A389B2-9D9D-4C1F-B9E3-9859C77DAF70@icloud.com> <798C9A13-7A2F-4C43-A5D9-6FDE00D647FC@icloud.com> <20190507131442.7hnyuqpknzldorur@Ergus> <20190509094915.zja6oba6dkpqnbpc@Ergus> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="43636"; mail-complaints-to="usenet@blaine.gmane.org" Cc: help-gnu-emacs@gnu.org, Stefan Monnier To: Ergus Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri May 10 05:20:56 2019 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hOw5e-000BCR-As for geh-help-gnu-emacs@m.gmane.org; Fri, 10 May 2019 05:20:54 +0200 Original-Received: from localhost ([127.0.0.1]:36064 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOw5d-0001CB-Ca for geh-help-gnu-emacs@m.gmane.org; Thu, 09 May 2019 23:20:53 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47188) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOw5P-0001BN-4K for help-gnu-emacs@gnu.org; Thu, 09 May 2019 23:20:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hOw5N-0006s8-JO for help-gnu-emacs@gnu.org; Thu, 09 May 2019 23:20:39 -0400 Original-Received: from pv50p00im-ztdg10012101.me.com ([17.58.6.49]:53742) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hOw5N-0006r5-BV for help-gnu-emacs@gnu.org; Thu, 09 May 2019 23:20:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1557458433; bh=af7Ae9d+3vHRx808UP5npVZ/ymmMZFdhxoPW2fI+jJc=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=rK8XuCAcm9LEPw5JHgAuFaewaHN/Q1CZxb9N02D57iHdV7MGqx7K5YHxNM8zDwy+Z sZY2v4UyFUI7llE17+qyflGWRDgZjAYV0sUMj/dUWqXp0uJqMjpZuPqSp/6SejvXRa iC8VIDkm7DrqX6UmhlBC/oPvmSyYRkdGv3JnYHu+lxk0ve3JjAP+rYv/iPuxNAGFtW y/x65KvxFRrD5Jlhthb3hragq4b9QrlRaGaWK1uKyudHmlWF9A3+HWllLt6Nl+UuOT g5DNcF96HYlMUDS7pOz6TM2xvZPv6HxK5/6PlIJkYphwp1nz/Wh+XgJQcy2HQ10Gkj 8V4IhEvwI3/Uw== Original-Received: from [10.199.120.22] (unknown [223.62.162.23]) by pv50p00im-ztdg10012101.me.com (Postfix) with ESMTPSA id 22A2E8409EF; Fri, 10 May 2019 03:20:32 +0000 (UTC) X-Mailer: iPhone Mail (16E227) In-Reply-To: <20190509094915.zja6oba6dkpqnbpc@Ergus> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-09_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1905100021 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 17.58.6.49 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:120277 Archived-At: I=E2=80=99m just dreaming, but what if Emacs goes the Stumpwm-way and implem= ent everything in CL? There are previous efforts; We might be able to build o= n them...?=20 =EB=82=98=EC=9D=98 iPhone=EC=97=90=EC=84=9C =EB=B3=B4=EB=83=84 2019. 5. 9. =EC=98=A4=ED=9B=84 6:49, Ergus =EC=9E=91=EC=84= =B1: > Hi: >=20 > 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. >=20 > 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. >=20 > ---------------------------------------- >=20 > 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. >=20 > 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) >=20 > 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 implyin= g > 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 tha= t > 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 SBC= L > 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. >=20 > 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. >=20 > Doug >=20 > ---------------------------------------- >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Stelian Ionescu >=20 > ---------------------------------------- >=20 > I expect portability to be a real issue here. If you *do* want to rely on S= =3D > BCL to generate native machine code for you, and abandon supporting platfo= r=3D > ms that SBCL doesn't, that would be OK. This would entail significantly mo= d=3D > ifying the Emacs runtime though. The SBCL compiler is married pretty heavi= l=3D > y to its runtime (mainly through the GC, which is written in C), and SBCL i= =3D > s a small C program which simply jumps to the Lisp entry point in a large L= =3D > isp image and stays there in its own world, with its own calling conventio= n=3D > and object layour, occasionally calling back out to C for operating system= =3D > tools and GC, which understands Lisp objects and calling conventions. So L= =3D > isp/C interoperation works very well, but as others have stated, it works i= =3D > n a very SBCL-specific manner. I reckon the hard part would be getting the= =3D > C engine for Emacs to fit in the picture, hence the suggestion to rewrite m= =3D > uch of it in Lisp. > But the reality is I sort of doubt that eliminating support for a wide var= i=3D > ety of other architectures is acceptable to Emacs. Hence the suggestion to= =3D > create an Emacs bytecode backend. This would solve the portability problem= ,=3D > at the cost of some efficiency. SBCL tries much harder than Emacs to produ= =3D > ce good code (by utilizing high level optimizations such as constraint (e.= g=3D > . type) propagation), however, so even then the bytecode produced by SBCL w= =3D > ould be superior compared to what Emacs can produce now. A problem with th= i=3D > s is that the compiler really does expect to be targeting a CPU ISA rather= =3D > than something higher level, so you'll have to be clever to figure out how= =3D > to set up the translation from the machine independent intermediate repres= e=3D > ntation (IR2), and Elisp bytecode. > Finally, another option to reap the benefits of SBCL's fastish code genera= t=3D > ion while not sacrificing portability is to figure out how to make Emacs a= =3D > portable Common Lisp program, through use of portable libraries for foreig= n=3D > code interop, graphics, and Elisp (through macrology, most likely). Then i= =3D > t will run on all platforms that have C compilers through other Lisp imple= m=3D > entations which do not target machine code (like ECL, CLISP, etc...) and u= s=3D > e SBCL for the platforms it supports. This approach is taken by StumpWM, w= h=3D > ich is fairly similar to Emacs. > =3D20 > Charles >=20 > ---------------------------------------- >=20 > 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. >>=20 >> 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. >>=20 >>=20 >> Stefan >>=20 >>=20 >=20