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, 3 May 2019 12:36:44 +0200 Message-ID: <20190503103644.63lccjehmzulaojn@Ergus> References: <20190502131827.GA28987@tuxteam.de> <83k1f8q39o.fsf@gnu.org> <87woj8bqho.fsf@telefonica.net> <83tvecocvv.fsf@gnu.org> <87sgtwboot.fsf@telefonica.net> <83muk4obfd.fsf@gnu.org> <20190502214006.4fdsinp7u5xuqvdv@Ergus> <20190503004416.xfuzzucflp6bxpuz@Ergus> 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="21289"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: help-gnu-emacs@gnu.org To: =?utf-8?B?7KGw7ISx67mI?= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri May 03 23:19:21 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 1hMfaL-0012u5-6B for geh-help-gnu-emacs@m.gmane.org; Fri, 03 May 2019 23:19:13 +0200 Original-Received: from localhost ([127.0.0.1]:37871 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMVZ8-0005Ph-TK for geh-help-gnu-emacs@m.gmane.org; Fri, 03 May 2019 06:37:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51480) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMVYk-0005Mw-7c for help-gnu-emacs@gnu.org; Fri, 03 May 2019 06:36:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMVYi-0003V9-NO for help-gnu-emacs@gnu.org; Fri, 03 May 2019 06:36:54 -0400 Original-Received: from sonic314-19.consmr.mail.ir2.yahoo.com ([77.238.177.145]:44642) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hMVYi-0003U0-Fg for help-gnu-emacs@gnu.org; Fri, 03 May 2019 06:36:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1556879810; bh=8kgKmATLMbyFvkkzg9IsQDoZnc9a9Jhqg1eniEUoe/E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=TSbKcYSm9kolz76IVuyoj6m51Qpco+TO55RF5XVVlEvclYI/W9SMxjvIuejBs2ldlTtDeeZBqR+VhKRxTFONN1ae0ZZKu5WAyVWuHRDDx4s2xNiBD8IoVREkbFQIY+J7VlcHW35u3lgJFAcSptOYTKJ9T1i0ja9f/VCwEl100wNcUu5BvndMp0v9kSoodc21k08MWPlcsmDmgNsxdX9A/3S2pWLtXcnDUR/qfMsZNlLlPixZPAH4McRemUPUUWtgKKi40cQDD4VMwO6mIeWCjFDnt22zHOm+0nxU5cgL/yDg2zLrdFePyeHXXeM6lsfQcgVvuSX4HY4PMm57vyinSQ== X-YMail-OSG: IcKj.zkVM1l5agX4nIrHZ1h_5byr9eom0yAP5Qj4Zx0JynGx6H3nUx0N7uIzway WXmS1lqkc2ehoSiHIc6.CX5Az8Iy_f8miJbO7K7BELQrasv6oPi6m2fgBDkagZGIjVqbVZxZYGJg kYh0sc8kb3Z7rtgU0hQbuzxx6I_u_Dn_VMF8BvHNmDmWbkr952cOHvVIpP1bF.zlNMnP_ZNFyRmH D.z09.1_HLFuBaDe7pGP80Ta69bJ7xEBrEkSFhLIL2p1VWItySW8Lb7lV3zE6KROFsysAFt3q6Qf RTps_RX5xjoVPVgvL7cBaXHhvjQTZKie7bCLX9qw_6NmvW9X5m4DHEfslS1hlFtgnjeBR8i_SNi1 epc7RAYkzjDdyiEKB9.rrWOeRZe313ZecEO0ulHMW72s_oXJS7tHC3SSi3_K3D3mipK47l0ZTU_g UbpSMpKKwK1mUyFzAm21.HLf20b4f0fJ_A0mmBz7uVvtwy79gJ5_kWAIbmIMeKp1VU0kqZ6kfd.N .e1Qt6nZGLILwK.qSICKUhu8XSxZuE8oC39jgeLd.D0.lwvukrTt8TYja4gP.9IhD_BWFzMH.UxG x9oktAYgEkKiME1N1hxjVgNq7QahoCDq1AYw_doM1h4dSNfoqi0Nw3zTk5rNbUdArryFUMYoK8Wt IG.FBr2ORMcEs524z3I2.4ZmBve_pc83AFUPe907mIy05ULbg8wEQmlgCq.rJyRXizzhagNu._2h gD7GCMb8NRS7jkez.LwuL3TuV0TXXVp8g.l08aaiWiCUfLyXfqOKaKTiyVn7ToMZ8nFvR1BcchbW nJDFdHfvOeKK1EmIIRs.cDl16dBDm34RX.qEQldIrf Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ir2.yahoo.com with HTTP; Fri, 3 May 2019 10:36:50 +0000 Original-Received: from 84.88.50.33 (EHLO Ergus) ([84.88.50.33]) by smtp418.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ed99ec21831a80f3d38e4b0fb0f9d383; Fri, 03 May 2019 10:36:47 +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.145 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:120168 Archived-At: On Fri, May 03, 2019 at 10:06:56AM +0900, ????????? wrote: >I became curious after reading your email :-) > >Since implementing a new language/byte interpreter (Guile, for example) is hard, and making it fast is harder, why doesn't Emacs leverage the Common Lisp environment????? > It is not a language issue I think, but a compiler/interpreter optimization level. >For example, (since CL and elisp???s syntax is mostly similar) can???t we implement Emacs based on CL (looks like there were ongoing efforts before like Climacs, Hemlock, etc???) and expose elisp functions in a special package named ???elisp???????? It would allow elisp compatibility (by running all elisp code in the special elisp package) while giving package writers access to CL libraries. Since legacy cruft can go inside the package ???elisp???, CL emacs APIs can remove/redesign some old APIs and remove technical debt. This would also greatly accerlate Emacs speed as CL is super fast especially when using with SBCL. > That was the emacs-guile approach. The problem was that nobody finished it. And if the whole project (means the core and more important developers) do not decide to go in that direction for a good reason (like they want to evict the bytecode interpreter from within emacs or they consider important to use a specific Guile functionality) then it won't happen. Also, doing big changes like that in emacs core code becomes a big discussion that takes loooooong time in the mailing list. >Are there any reasons (that I do not know) why CL was not considered or was considered but rejected as an elisp alternative? >Are there license problems to build on previous attempts????? > maybe it has to do with this: https://www.gnu.org/gnu/rms-lisp.en.html >IMHO building emacs on CL would be a wonderful idea... and would fix many problems that current Emacs have. > And create others, it is always a trade of. Any way I have to say that comparing to other interpreters around the Elisp is not the slowest one I have tried by far. Of course it could be way faster, but some optimization like user code and provide new containers and datatypes in the library level based in C (and recomend them) code could potentially make more difference in real user extensions. >> 2019. 5. 3. ?????? 9:44, Ergus ??????: >> >> WARNING: This email has plenty of personal opinions. >> >>> On Fri, May 03, 2019 at 08:39:43AM +0900, ????????? wrote: >>> >>>> Probably (I have a dream) if someone decides to develop a new emacs in >>>> 2019 most of the functions and API will be made in pure and clear C (or >>>> any other compiled language), with a full C api that gives the same >>>> access level than what elisp gives in Emacs today (with C lists, arrays >>>> and structs), so it will be not only faster but also simpler to extend >>>> it with other languages like Scheme, Python, Lua, C++, rust and so >>>> on. (There are modules projects going in that direction) And the editor >>>> don't even need to provide a compiler or interpreter for them. (there >>>> will be Guile/gcc/python and so on for that) >>> >>> This, very much sounds like Guile Emacs. Anyone knows how Guile Emacs >>> is doing????? It???s very much looks like vaporware these days :-( >> >> Yes, that is the dream (at least the closest we have ever been) >> >>> Is upstream considering Guile Emacs as a valid solution? >> >> I made a similar question some time ago and the answer is that there is >> not action. :( In fact there is not too much action in >> Guile's development . >> >> Not many projects feel interested in Guile because the weak support it >> has so there are few users and few developers (But also because >> Lisp-like family languages (common Lisp, Scheme and the others) are a >> museum piece for young generations that are more used to Python, Ruby, >> javascript, and most of OOP (also because there are more jobs with >> that)) >> >> Actually I think that these days will be easier to find new C/C++ >> developers for emacs than Lisp developers. Lisp and Scheme are >> beautiful, but they require a different way of thinking and a lot of >> time (own experience, I am just starting with it.) One reason why I >> can't convince my friends to use Emacs is actually how Lisp scares them >> ((())()'()). >> >>> Is there any development ongoing? (Official or not?) >> I don't think so :( :( :(. It will require that some core emacs >> developers feel more interested in implementing this, because it is a >> lot of work... (specially to do it right and keeping the so sacred >> backward compatibility) These days only few people know the core parts >> of emacs for such a task. >> >> Having Guile as a dependency will grow emacs size significantly >> and using it as an external dependency (not usually the emacs way...) >> will require to port Guile to more systems (AFAIK). BUt such desition >> could benefit very much both projects. >> >> There are even some emacs ports to rust (remacs) but they still have the >> elisp as the core languaje. Because most of the code and functionalities >> are already in elisp so changing that will be like reimplementing all >> emacs from scratch. >> >> (Some time ago there was a lot of effort and time invested in porting C >> functions to Elisp in emacs) >> >> So with our actual emacs maybe the JIT or the Lisp->C source to source >> is actually the more reliable option in a possible (realistic) future. >> >> Personally I feel the Lisp->C compiler feels like the faster and more >> robust solution for me, but it will create a dependency with >> binutils... which is for multiple reasons undesired. >> >> The alternative JIT may be based in libJIT which is not very active >> either... and has serious issues/limitations that has not been solved in >> years. >> >> [1] https://tromey.com/blog/?p=982 >> [2] https://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00393.html >