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 13:35:09 +0900 Message-ID: <10734603-6076-456A-B3C9-1C1BD364E7F6@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> <9C8C6E45-4E41-489C-AE75-80B52569586E@icloud.com> <425EF747-8522-48E1-ABB7-0648F0F29E54@aol.com> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) 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="92942"; 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 06:35:39 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 1hOxFz-000O3I-9t for geh-help-gnu-emacs@m.gmane.org; Fri, 10 May 2019 06:35:39 +0200 Original-Received: from localhost ([127.0.0.1]:36702 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOxFx-0004yF-SK for geh-help-gnu-emacs@m.gmane.org; Fri, 10 May 2019 00:35:37 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56144) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOxFj-0004vU-3I for help-gnu-emacs@gnu.org; Fri, 10 May 2019 00:35:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hOxFf-00057z-VA for help-gnu-emacs@gnu.org; Fri, 10 May 2019 00:35:23 -0400 Original-Received: from pv50p00im-ztbu10021601.me.com ([17.58.6.57]:54738) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hOxFf-00056q-LB for help-gnu-emacs@gnu.org; Fri, 10 May 2019 00:35:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1557462916; bh=zdE9kiP0M5vGt+Zk9BR7RE+Iaq3/lL5gPW+fUmyuS2o=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=aawBEoGVRgqXXmOnLEDLDjZxdcAjOj0NuGtj2WvSspfYnzCf/qjd3cvSOsPzhB1Uw Nmd3/DRG8x9I3oziBMxa+8+NgADbP7QGaewY2mEXj+kobUjyh6Bvd6TtsBuF0JOYx3 x3hl3cPCvfnqrU9zoR6UlP5Niye6xxuUvDM7b0M/Uo5QK6hBXEIeyJyK1spJ84YKob OqTxkJVELrg4YfjnP2EsJbQ3QP7XGSGD4u8rtvzoLwGdeg4RnvqDGv0ZGgyT98yxYv ZAXLybTOmswQ/6g9ULKoPsgKWO+NWYTxgA3TGIiVagLWX/5YudZyD8NLthbBj5eyG4 4Qn72HNQrmHUw== Original-Received: from [10.56.218.39] (unknown [128.134.203.66]) by pv50p00im-ztbu10021601.me.com (Postfix) with ESMTPSA id 04BF16E0310; Fri, 10 May 2019 04:35:14 +0000 (UTC) In-Reply-To: <425EF747-8522-48E1-ABB7-0648F0F29E54@aol.com> X-Mailer: Apple Mail (2.3445.9.1) 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-1905100032 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 17.58.6.57 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:120279 Archived-At: I understand why this is impossible or near-to-impossible; but... > 2019. 5. 10. =EC=98=A4=ED=9B=84 1:26, Ergus =EC=9E=91= =EC=84=B1: >=20 > I considered that possibility. >=20 > 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. xdisp.c is a cross-platform (#ifdef-containing) low-level function that = handles displaying=E2=80=A6 C functions like that can just be imported = with FFI and be used. Many CL compilers (such as SBCL, CCL, etc) are actually super-optimized, = and emit code as fast as most C compilers as the language was used for a = long time; With some type hints in low-level functions, SBCL emits assembly as fast = as C :-) As for remacs, I=E2=80=99m pretty sure GNU Emacs have much more manpower = than Remacs; and Emacs don=E2=80=99t need to migrate all of C code; only = the portion that implements Elisp functions. > But we have the scoping differences with common lisp, so that will = also force big updates in the lisp code=E2=80=A6 This can be mitigated by implementing Elisp in CL (as we would have to = do that) and run the code in the Elisp package. > 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 = implement everything in CL? There are previous efforts; We might be able = to build on them...?=20 >=20 > =EB=82=98=EC=9D=98 iPhone=EC=97=90=EC=84=9C =EB=B3=B4=EB=83=84 >=20 > 2019. 5. 9. =EC=98=A4=ED=9B=84 6:49, Ergus =EC=9E=91=EC= =84=B1: >=20 > 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. > 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 = 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. >=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 > 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 > 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 = platfor=3D > ms that SBCL doesn't, that would be OK. This would entail = significantly mod=3D > ifying the Emacs runtime though. 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. = 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 = vari=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 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. > 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). = 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...) = and us=3D > e SBCL for the platforms it supports. This approach is taken by = StumpWM, wh=3D > ich is fairly similar to Emacs. > =3D20 > 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. >=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 >=20 >=20 >=20 > --=20 > Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa = mi brevedad.