From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.help Subject: Re: Why is Elisp slow? Date: Fri, 10 May 2019 06:26:57 +0200 Message-ID: <425EF747-8522-48E1-ABB7-0648F0F29E54@aol.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> <9C8C6E45-4E41-489C-AE75-80B52569586E@icloud.com> Mime-Version: 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="55937"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: K-9 Mail for Android Cc: Stefan Monnier To: help-gnu-emacs@gnu.org,=?UTF-8?B?7KGw7ISx67mI?= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri May 10 06:27:38 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 1hOx8D-000EMR-Ep for geh-help-gnu-emacs@m.gmane.org; Fri, 10 May 2019 06:27:37 +0200 Original-Received: from localhost ([127.0.0.1]:36626 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOx8C-0002uU-EN for geh-help-gnu-emacs@m.gmane.org; Fri, 10 May 2019 00:27:36 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55165) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOx7u-0002uC-IX for help-gnu-emacs@gnu.org; Fri, 10 May 2019 00:27:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hOx7o-00012w-HA for help-gnu-emacs@gnu.org; Fri, 10 May 2019 00:27:16 -0400 Original-Received: from sonic313-22.consmr.mail.ir2.yahoo.com ([77.238.179.189]:40088) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hOx7m-00011T-C8 for help-gnu-emacs@gnu.org; Fri, 10 May 2019 00:27:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1557462427; bh=DhXRSGYaXhSfOXw2X9i9zRrEppN9dM/Gf99DsZKRJNs=; h=Date:In-Reply-To:References:Subject:To:From:From:Subject; b=rW1nXU3CpVGQaFEf674S87WbJun2wPtlZTWTVYiUMs/5oChUKOg9Cl3Os+eRvCKsMHt/biv92fz7F7Dk4MjLWpCA0ohu9IYdLUG+4S92oBXaBUshixWYP6m2A/W7Sx90ew9/Rnpk36aXZ1QewKs80BKZDg/ajl7A5eiKSYonXFGb96UwksnK96bisp4pGRX0SBvqX5AeWOoKY1D9rti9EToi/OQCjsxySrO92sNjWnIqxymH5RkfijcpvR354MKngSb+DU5miDQjzIIz9wobka+OzFwDZBuZgu52G7tyqR0BtBzEXyxsGEFO33B8yeBfg8RkJpKpRS2MSqjtmrTGTw== X-YMail-OSG: b.USsRAVM1ld0AIdWLMioxXdZk_tkSX40LUN6Cfl.rL92IXEe7hz1nxeWu0SAYe 5K2uxCZfxZzN5WxMv1jDmMK7uSZe9GTa8Yb76aL0oN2sZNr684VBKKsVoTTLitwjeB472K238PEq 0HVh4ESJt2te9SoP1G8o0a9DoZYZ6YBjqQWwCsv9iDUTjXdYsHXmqyKmu0_1cBBrSg7gZS4_PfGD DRGOMiHktKLnsBdSMEIBB9jAoDww45.NRyLHczPuZnXxO6RzoMohgUZSXYw7BE36bR5wUtsXmDQ5 s5l4XxTIN21RGrB.Djwk1iqjI_DHdZlo5KQm88Qc1_HnGsBLtvtVdFVBbSdfYCG.4MGGQ12iWE_q bCLnDHGH2Xlr015fV.MQFUz1T5YP6qhVJus9EhvrbK00_9jilgG7IHcG9Rm5niZUQqVSc4sVDPQS 0J4Em4MJhS7qF_62PfTAi9CKz57uimjk1Lk0OEXxlfDMmOgmjZsq_sdeGrEK4mBkgBPCWETE5f.T 96aOd.uxZQR7.cwPIr5_5..1x4P8oAXEinWb56.svnqzJlkLnB82TgF.DST496gJ2kQZvgDNrtnD YoL74yX6S6x2pWPRa60r5OSC2aEphSYCwCjKj1G6eAZIfH4W7UP5SYG0zr3M435jHTMjcR4BLtpo EagXK5DUnBnzqbT75M8xHScqwJHWBm7AN_MakFAI6d7xybX1FfkAmP.E2XSUoc4lSBR6Yul2eoZn am.lf5HjsfINm10R7UYWzHCjo2lgKZO0zieSW3TATlrCg4nPm9zQNhWRHQuIY67wTJUMYj4BkmjD qncZQdVR12FX_BIcdSKNyNO6SxidwB2y58e20kQ66c Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ir2.yahoo.com with HTTP; Fri, 10 May 2019 04:27:07 +0000 Original-Received: from 2.152.205.184.dyn.user.ono.com (EHLO [192.168.1.44]) ([2.152.205.184]) by smtp407.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d6832c5be09b545a96acade7a8a5b7c7; Fri, 10 May 2019 04:27:02 +0000 (UTC) In-Reply-To: <9C8C6E45-4E41-489C-AE75-80B52569586E@icloud.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.238.179.189 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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:120278 Archived-At: I considered that possibility=2E Give a look to the files sizes inside src in Emacs sources=2E Only xdisp= =2Ec, for example, is more than 33000 lines=2E Projects like remacs are mig= rating the C code to rust and they have needed years and only moved small p= ortions=2E Also the lisp compilers aren't as good optimized and mature as G= CC for example=2E And big changes will make the code unfamiliar for our dev= elopers=2E But we have the scoping differences with common lisp, so that will also fo= rce big updates in the lisp code=2E=2E=2E On May 10, 2019 5:20:29 AM GMT+02:00, "=EC=A1=B0=EC=84=B1=EB=B9=88" wrote: >I=E2=80=99m just dreaming, but what if Emacs goes the Stumpwm-way and imp= lement >everything in CL? There are previous efforts; We might be able to build >on them=2E=2E=2E?=20 > >=EB=82=98=EC=9D=98 iPhone=EC=97=90=EC=84=9C =EB=B3=B4=EB=83=84 > >2019=2E 5=2E 9=2E =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=2E >>=20 >> I'll copy-paste the main answers here just in case someone wants to >go >> this way in the future=2E Or in case someone more expert see some >possible >> workaround for the issues exposed here=2E >>=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=2E Instead you'd like to >> retarget the output of the SBCL compiler to produce elisp byte code >for >> execution=2E >> It's unclear whether you'd expect this to be an out-of-process >compiler or >> an in-process compiler=2E If in-process, then you've got larger >problems >> than figuring out how to call C=2E 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=2E >>=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=2E 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 '=2Efasl' file and into emacs=2E The "machine code" in the '=2Ef= asl' >file >> would actually be emacs byte code=2E (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=2E SBCL uses C >> functions all the time=2E In fact it is extremely interoperable with >C, but >> that's really asking the wrong question imho=2E >> Portability is the real question, since you brought it up=2E 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=2E >> First of all, SBCL can produce machine code only for a tiny fraction >of >> the CPUs that emacs supports=2E 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=2E SBCL's compiled lisp files are not a >portable >> abstraction like a '=2Eo' file (or '=2Eso' if you like) that could be >loaded >> into *any* other program (a C program, Java program, etc) and just >run=2E >>=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=2E >> So that would be essentially 1 new architecture that SBCL would have >to >> support, namely the emacs virtual machine=2E 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=2E >> You'd have to invent that as part of the retargeting to the emacs vm=2E >>=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=2E >>=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)=2E 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=2E >>=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=2E >>=20 >> Stelian Ionescu >>=20 >> ---------------------------------------- >>=20 >> I expect portability to be a real issue here=2E If you *do* want to >rely on S=3D >> BCL to generate native machine code for you, and abandon supporting >platfor=3D >> ms that SBCL doesn't, that would be OK=2E This would entail >significantly mod=3D >> ifying the Emacs runtime though=2E The SBCL compiler is married pretty >heavil=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 >convention=3D >> and object layour, occasionally calling back out to C for operating >system=3D >> tools and GC, which understands Lisp objects and calling conventions=2E >So L=3D >> isp/C interoperation works very well, but as others have stated, it >works i=3D >> n a very SBCL-specific manner=2E 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=2E >> But the reality is I sort of doubt that eliminating support for a >wide vari=3D >> ety of other architectures is acceptable to Emacs=2E Hence the >suggestion to =3D >> create an Emacs bytecode backend=2E This would solve the portability >problem,=3D >> at the cost of some efficiency=2E SBCL tries much harder than Emacs to >produ=3D >> ce good code (by utilizing high level optimizations such as >constraint (e=2Eg=3D >> =2E type) propagation), however, so even then the bytecode produced by >SBCL w=3D >> ould be superior compared to what Emacs can produce now=2E A problem >with thi=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 >represe=3D >> ntation (IR2), and Elisp bytecode=2E >> Finally, another option to reap the benefits of SBCL's fastish code >generat=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 >foreign=3D >> code interop, graphics, and Elisp (through macrology, most likely)=2E >Then i=3D >> t will run on all platforms that have C compilers through other Lisp >implem=3D >> entations which do not target machine code (like ECL, CLISP, etc=2E=2E= =2E) >and us=3D >> e SBCL for the platforms it supports=2E This approach is taken by >StumpWM, wh=3D >> ich is fairly similar to Emacs=2E >> =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=2E >>>=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=2E 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=2E >>>=20 >>>=20 >>> Stefan >>>=20 >>>=20 >>=20 --=20 Enviado desde mi dispositivo Android con K-9 Mail=2E Por favor, disculpa m= i brevedad=2E