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: Thu, 9 May 2019 11:49:15 +0200 Message-ID: <20190509094915.zja6oba6dkpqnbpc@Ergus> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="49606"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: help-gnu-emacs@gnu.org To: Stefan Monnier Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu May 09 11:50:06 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 1hOfgj-000CkV-IV for geh-help-gnu-emacs@m.gmane.org; Thu, 09 May 2019 11:50:06 +0200 Original-Received: from localhost ([127.0.0.1]:51505 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOfgi-0007s1-Ig for geh-help-gnu-emacs@m.gmane.org; Thu, 09 May 2019 05:50:04 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35804) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOfgX-0007rk-1b for help-gnu-emacs@gnu.org; Thu, 09 May 2019 05:49:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hOfgV-0006Ha-5l for help-gnu-emacs@gnu.org; Thu, 09 May 2019 05:49:52 -0400 Original-Received: from sonic305-19.consmr.mail.ir2.yahoo.com ([77.238.177.81]:36131) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hOfgT-0006GM-9n for help-gnu-emacs@gnu.org; Thu, 09 May 2019 05:49:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1557395386; bh=DysWPsM6Z2Oj04zRVaunne/duzIftZk+LLVkBFdgJzc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=OE6Jtx5W6LIA/spQ4CU6UgQg+3Z+ojv0utepQy6qZBpI1K7cedym6SYbsy9klopVSin1KLm1qEmUIIkV7x2uG4BfsLARRyec/O7vMnmJA4dCasKZMDzWSiKICZD3jmq+nE8xJlKIlwRxTUmLgd+0+ox9Qs/EvYfG3THbmGE2Ve+aXpzHV6czhjvqcH22TA4gbFlkKFY/umOTC0DpdHKYQwIczYZel+hHAyoxT8pH+v2QUFkENAQpeiSohETCgdG5xfveD7jqeNfaos/UQ/JhXuP19Tm2QeYMG4RAMW+yaXX3QdGzuNg+TMe1qZFMC9btpJip9xoAwbON2lDXqQjJPA== X-YMail-OSG: WF8gQv8VM1mZekWJb2djSEi0OCexhXgklNpwq003vGokW6Jq5y8b6cI7kKBi3u4 Vm3r5VgPUU05x8eY5.GwAYDdtNty7GeDYUAcsDSHef17pWcHQZFLWDzyA.GClzSAWlxyQF2ULckn MZrQYC9LEaGu0HlVMdzACp0Ics47OLNGvSLhujEhZ5K2B57HB8s4QfE0T83Sj5Q3HZbCMRSXT8uw cbOUCRLgilTEh67i.qRq5qHYvci.QAoT3jXEFPsodREoV7z4uhtl6Q2kpYspV6Y5uczUep6oRy8U 8C195zCVTc49uV8KpuqOlNwAPXB7ItMWUTfd7GYcNmvQeTJUo4SIbE_h4zHIIwZFKSruWbWCQu6m fj.8qkOUJy3kE_Je8NvRrX.Q_lG3ytWbU8xvhhHBey20FrT22ko60wTu8eKsJyi6yWAKcYsTcA_6 nyIux2ghlg70CIy9X2rdStGXyl6mdAB9LfCwV2br.5q.UasCArB5yFksDT_5mg0A5WVt2tkYOG3K g5_Vr6LsHjo5_QU8J3vap7fXmr9UcZbtz5WJeo39u00iQajZe7Lzp4y4UEeUHewNidiMQzZ4P2Kp q.WoJWM4m2Fw9dnPetAIzsVg8MvW_nlVygc7zfGZc1XYxnjKLLn_to9Mq77kn0xq7GTKG4ItMVVg FJslMN4nHRr878Sm89ddXd9d6aQ2SGJX3gxnTpXanouN1ZulhDaTt7LaCFsrkTNTGV8BWM.VMWX_ EYfoLFm5QDtPVhJeiUPR_QbeBTURmqLFgVF37sWx1rEhXiY6VKcGJj3olVBO6vxyOvmR5GaT_G26 GDJYhlrGq7DhkTssDt1z592FsYUR4uBPBDBfHBtBAi Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ir2.yahoo.com with HTTP; Thu, 9 May 2019 09:49:46 +0000 Original-Received: from 2.152.205.184 (EHLO Ergus) ([2.152.205.184]) by smtp416.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1e992eac3e899ce8067c1bc75fc7b6e6; Thu, 09 May 2019 09:49:41 +0000 (UTC) Content-Disposition: inline In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.238.177.81 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:120272 Archived-At: 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 > >