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: Tue, 7 May 2019 14:38:04 +0200 Message-ID: <20190507123804.txa7xq26tmw53kmw@Ergus> References: <20190506125848.okei2qrib7m5p3vx@Ergus> <20190506161757.wg4wy3vr7emxnciv@Ergus> <443E6AB4-2478-4677-8A23-A0B04559E949@icloud.com> <84F2860D-523D-4F30-BD52-D6A915416167@icloud.com> <20190507104945.gfdrftaeztrzbkt6@Ergus> <44A389B2-9D9D-4C1F-B9E3-9859C77DAF70@icloud.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="199599"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: help-gnu-emacs@gnu.org, Stefan Monnier To: =?utf-8?B?7KGw7ISx67mI?= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue May 07 14:38:44 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 1hNzMm-000pkX-Si for geh-help-gnu-emacs@m.gmane.org; Tue, 07 May 2019 14:38:41 +0200 Original-Received: from localhost ([127.0.0.1]:46152 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNzMl-00040f-SR for geh-help-gnu-emacs@m.gmane.org; Tue, 07 May 2019 08:38:39 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNzMO-00040M-2X for help-gnu-emacs@gnu.org; Tue, 07 May 2019 08:38:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hNzMM-0004wg-GZ for help-gnu-emacs@gnu.org; Tue, 07 May 2019 08:38:16 -0400 Original-Received: from sonic313-20.consmr.mail.ir2.yahoo.com ([77.238.179.187]:41657) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hNzML-0004vw-Fu for help-gnu-emacs@gnu.org; Tue, 07 May 2019 08:38:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1557232691; bh=nVfutXPQlzTxGd/BP7GDRxAPWYXRWCV9Raj+x7O12bk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=RToKRVXYG/3gwQE0btldpg3GH/zbjOGpve5vRHuhDxZGRVMlDXUuDW33VltbuhV6IwaD1cVsaePkWohV8Gzj6bzgVqs7cUfVvOsjHhz96RhpEP0FweyBhalQVjT0sSlTeDC1nS5Aieoyu6eF4RH/Pi0aNVjPuyP/FC5d5IsBzsD+XblFnj7ecla4zuvtdbqxV+V0+QMUxj89qMjKcn4qTJ7czRC9Hi1eNJ58UQwZPqeZ+tvtZNz7Q/Jf4me4KABRWbxlpefZ1EJ6xPUhxLP7VZ9ygvmoW3OMcuq7oly1eEmyVjOt40bBTJRqYC3o52XFuncyqjPYUuNGX93vd30ATQ== X-YMail-OSG: QFNO7fQVM1mCM1JpfR2eJ7a6gG94z1wqbUpGf9oU4suPzpjmQhJd4Ulp0W1ariY s5stA8ALmF4ixF8ZE94m3nN6lrPytzmt6_CiLLnh.9gT0fDQq0NhlnepgrLr6g1EcyYcVbevmPsL Q0GMlWkb6jgoA0Sb4SqXAsL4S36gixwUvvBXY2Zj57FOEM8DbIJZI8OrEIyhTq01lev7egWFjwMT 7sGaRvSPMQHcdZnUpH25bSucqL2djWvNJ.0O2NVHJ7QJj52.uCTw6DG3uFWHGmf1k_5yk.TQFaDp szhPL2T0P3R1P0__XdOCV3zBeWqjjyfuSkoFhGV9R5mxVnsWhedDXOeDpNDhfEph5XXgUrLSOU1Z SMB5wPL91S3gzlv8t_AqIFBFbTjZCcqdWl3.X0vzttL_HGji2Pcoa6ySwP94qrX.G20Wx4vcFWPt 3ektY763iPwHUOBGOaYAdp7PrpOPJu7xhDVgR6CzIS7mN_bTT_s0D_NTqvwW0g6xpvOUznISWsQo 7EQV9qmZVr1RsFf0aGdtKEc1Ef_r8LQ80HD0D1dCIjLwH3AL6cWpiX9z1n1NyvPmmhVcQSdMTWgw 7EHFIYBnFNzRId99cjbxL2nP6VdA310CqmifAr3BATRNEHCQZ4zDeAtp9D4xgDlrTAkAkL53QTh9 otwMvB06g4YvwLZmkNwdHjekpF4uMPWCAAVMJmmVIkaLb76g29BN0ecAz4q9wAj1bjdg5ckgUHAS KMZQYVjXW0wIEoMfH5Plb8lNI4eZu5xd.sxmFvFayHvFPrPf51jr9RZrLk3GemumqdaNAAPZhlbO 1JnM95OUvDyjB39pAtGmBv6e40Kv41QX2.kJ_T6ZBy Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ir2.yahoo.com with HTTP; Tue, 7 May 2019 12:38:11 +0000 Original-Received: from 2.152.205.184.dyn.user.ono.com (EHLO Ergus) ([2.152.205.184]) by smtp417.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ba9c2170f6c83fc6c1d5dadf56a191f0; Tue, 07 May 2019 12:38:08 +0000 (UTC) Content-Disposition: inline In-Reply-To: <44A389B2-9D9D-4C1F-B9E3-9859C77DAF70@icloud.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.238.179.187 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:120251 Archived-At: On Tue, May 07, 2019 at 08:51:27PM +0900, ????????? wrote: > > >> 2019. 5. 7. ?????? 7:49, Ergus ??????: >> >> Hi all: >> >> After reading the whole SBCL manual and the internals I have some >> comments maybe useful if we decide to go in that direction. (If some of >> the core developers starts with this I will be very pleased to work on >> that, but I am too new in emacs development to start it myself alone.) >> >> 1) + Portability does not seems to be a big issue, they already support >> our architectures (and some extra) and they are putting a lot of effort >> on that. There is work to do, but in general, they already have what we >> need from Common Lisp. >> >> 2) + They have documented how to port SBCL to new architectures, and some >> of the optimizations they implement, so, if we have a compiler >> specialist on board and finally our developers choose not to go for >> SBCL, then maybe some of those optimization could be considered for our >> Elisp compiler. >> >> 3) - There is not C binding for SBCL. To extend it, there is not a >> public-documented API and their approach is wrapping the C functions >> from Lisp (FFI). I wrote in their mailing list and they redirected me to >> the CFFI page. >> >> + The only advantage (I see) in this approach is that as CFFI has >> been ported to almost all common list compilers/interpreters; if we >> go in that direction for our C code we could potentially use any of >> those and jump from one to another at configuration time. So we >> don't have this problem (of being stock with a "bad" compiler) >> anymore. >> >> - The overhead produced by wrapping in the high level instead of the >> low level in my experience (python, ruby, Julia) is usually much >> higher than having C bindings. >> - Writing wrappers in lisp for all our C functions exposed to Lisp I >> think is not an option if we don't create an automatic method. So >> if no one creates a plugin for sbcl to support Elisp, I really >> doubt the feasibility of using SBCL except if many of our current >> core developers agree on that and join effort for that. Else it >> will happen as with guile. > >There is an automatic method of generating C FFI bindings from header files. >See https://github.com/rpav/cl-autowrap :-) >What I was thinking about using CL to support Elisp is to define a new >namespace for symbols (which, in CL terms, is a so-called ???package???) named ???elisp???. >All Cl-needed functions/macros are defined in the ???cl??? package, >which means that you can call any cl function/macro by >prefixing ???cl:??? in the ???elisp??? package. This is what I understand as a plugin for SBCL. Because we will need some steroid for that :p >As CL and Elisp has many common things (such as the similarity of >many, many macros like ???defun??? or ???defvar???, etc??? or that it is a Lisp-2), >we can implement elisp entirely inside CL itself. >No need for developing a plugin specially for SBCL; any CL implementation will do. >For functions defined in C, we can make or generate wrappers to get >passed-in-arguments and dynamically wrap values into a Lisp_Obj C struct >(AFAIU all lisp objects are represented as a struct of type info and some pointers, > am I right?) and call the underlying function generated by cl-autowrap. > This is so huge that I don't know where to start looking :(. What I was looking was a representation of the types in SBCL, but I couldn't find that. AFAIK cl-autowrap is to wrap simple C functions with C types and structs, but Elisp actually has it's own representation of lisp objects and functions. And the exposed functions already have a unified function format to store the pointer in the function's hash table. If we use a wrapper on the hight level we will be packing and unpacking structs (copies and more copies) constantly and wasting the advantage of having a similar representation. Or we won't be allowed to pass Elisp object to CL functions. So the first to do should be to unify the Elisp types with the CL representation as much as possible and check the differences we can't solve implicitly to create an explicit conversion when needed. Because with guile, after doing the hard work, we found that there was a problem with strings representations (if I understood right what Stefan explained) We also need to find a method to create lisp objects from C to implement DEFVAR_LISP, DEFSYM and similes in C if we don't want to reimplement big portions of code (like the display engine for example). There is still the problem with buffer local variable that we don't have a solution for that yet either. Then we can start checking the functions we have that are Elisp agnostic and can be compiled with SBCL. We could also have another set of functions we have implemented in C we will not need anymore and finally there will be functions we need to wrap (like everything in editfns.c for example)... But again... this is huge. > >> 4) + With FFI as they implemented, it will be pretty easy to interface >> and call C libraries and functions without needing a C wrapper to expose >> it to lisp, so maybe an important part of our C code could be >> substituted with Lisp (simpler and smaller) glue code. But also we will >> be allowed to use C dynamic libraries directly without all the modules >> complexity. (Somehow I feel that not everyone will like that if we >> comment it in the developers mailing list :p ). >> >> On Mon, May 06, 2019 at 02:47:12PM -0400, Stefan Monnier wrote: >>>>> [ 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? >>> >>> Exactly because the version that can run on ARM is not the same as the >>> one that can run under Windows, which is not the same as the one that >>> runs under AMD64. >>> >>> Of course, maybe I'm confused by the table of available binaries (at >>> http://sbcl.org/platform-table.html), and in reality the latest version >>> works fine on all supported platforms. >>> >>> Stefan >>> >> >