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 12:49:48 +0200 Message-ID: <20190507104945.gfdrftaeztrzbkt6@Ergus> References: <831BD780-F954-4E23-BF31-ED4E135C919B@icloud.com> <20190506125848.okei2qrib7m5p3vx@Ergus> <20190506161757.wg4wy3vr7emxnciv@Ergus> <443E6AB4-2478-4677-8A23-A0B04559E949@icloud.com> <84F2860D-523D-4F30-BD52-D6A915416167@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="267675"; 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 Tue May 07 12:50:20 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 1hNxfw-0017VM-5F for geh-help-gnu-emacs@m.gmane.org; Tue, 07 May 2019 12:50:20 +0200 Original-Received: from localhost ([127.0.0.1]:44364 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNxfv-00071E-4r for geh-help-gnu-emacs@m.gmane.org; Tue, 07 May 2019 06:50:19 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33064) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNxfc-0006zU-8A for help-gnu-emacs@gnu.org; Tue, 07 May 2019 06:50:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hNxfa-0006rb-SL for help-gnu-emacs@gnu.org; Tue, 07 May 2019 06:50:00 -0400 Original-Received: from sonic307-53.consmr.mail.ir2.yahoo.com ([87.248.110.30]:38618) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hNxfa-0006qv-0M for help-gnu-emacs@gnu.org; Tue, 07 May 2019 06:49:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1557226196; bh=WU9OAZt2DMMfK1bFT9WLUxY56ibWjNRV+DKlTUNOphA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=NhFoCdUqkFIW5jUbiYu3ZfbWnq/LUCS94YDeJ5jA/XS9y0srN8NXXQcOICojENwBKOpj6/AKLjovl+nb21wgqQKf3AsT/Ur2XbGdHy2gxPNEDdomBrQhGLFgLG2lqldrDdVDj/JOb2bPjilZA07rMxWX9zu/yzX4v1mxLMNy7XNtArYP2vZXCHfa604fPsPyF/wEGFcS7MaALT1dLJmxwibMCDBt/ar0Slm+QEBB9e6+mwFp/YuMe/DKehy079QukCYRPCrA4Oh7/WSl1UBKcpJThfWUi2IPzR/0/jnvsRY0OZYW9V56YPOiOWjFREr+db7/XsgpMDRTUpdInbBUWg== X-YMail-OSG: YLiUVK8VM1kagdMGVxv.htW7oJkNjcklVfGUyzUBrab.ypXYYStihlKn3o9V.Vy pS8nz2OFsZkVb2A7Tiz2YLLZdrxnTGD1UY4Dij8vc0f2dE3e_eaqbcGUnzGJtbbyyMNHemUj1xH2 7wf_mzXncuEMSeEVpflhAcIp1P3R.6TGV_hPBYFBT5C_9x.wYSVhsXduAKFin2fQrb_iiEsmOLzx 7gg5gBLTRclfwHrt4HIpvxpFzvhOHmx9Gtg01Gb4nRZp4ay4lVSAcSyrM5wrrrwdhLg0T7qfo3QN W8toEeddCLo7l2CzTTjpwQwCtf1R7pkMxfu5nBFczAEWmR6fENR0BajKdInsrStdPA1Cvo2sWUgl tmzAwgo04oAbAkE3wSHidsod6FSrqjnXnnNWs3QNH3cMW4_Os8.5tUa9.frlwJ3aMFar3pFyn0op C2XQ3fsqrbwXCk.2.FALFoyXGI8VuUcdU3UA9Kqe5Mxlmxx1VqydSnSL19hupcj7FpezSV0mFitH LbIbOD3CiM7sLx2wENVKMjWXOsmvzbwUTnEUKcd75j9dfiE0pVkhZn7tl6_xmJjux_LsaEC68j6g OWgf.C21v1w.wmRNXxcMjv4VdEwO7m3UZR111dC0YSnrcBxGgC5v0as.rFZZ3VhL8CPHwsi4oZEf 2xGrHuXPIbgcrD91D_5bGf8hryiu8X2EBPnSroX_TqUixewsmZiJ0JDR9WttqU.AdNOfVuas1nFk TEzf9Lavi54t21AxgrWBtM3fWQRRhu213WMiSdBc2pSH0wICLrlMGv0FkWSQeErdOtyl0WGnug5w 04JG_SFu0vho0gjWjph14MxISLTNTw61isCgCSPv2t Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ir2.yahoo.com with HTTP; Tue, 7 May 2019 10:49:56 +0000 Original-Received: from 2.152.205.184.dyn.user.ono.com (EHLO Ergus) ([2.152.205.184]) by smtp407.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 86058f911b33983e0b43c35ef692158f; Tue, 07 May 2019 10:49:50 +0000 (UTC) Content-Disposition: inline In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 87.248.110.30 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:120249 Archived-At: 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. 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 > >