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, 3 May 2019 20:52:06 +0900 Message-ID: <456EE4D4-F542-4F6A-B146-E6B9D72AE93B@icloud.com> 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> <20190503103644.63lccjehmzulaojn@Ergus> 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="17640"; mail-complaints-to="usenet@blaine.gmane.org" Cc: help-gnu-emacs@gnu.org To: Ergus Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri May 03 23:18:53 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 1hMfZr-0012u5-OR for geh-help-gnu-emacs@m.gmane.org; Fri, 03 May 2019 23:18:43 +0200 Original-Received: from localhost ([127.0.0.1]:38960 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMWk0-0002s3-TW for geh-help-gnu-emacs@m.gmane.org; Fri, 03 May 2019 07:52:36 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMWjn-0002rr-1C for help-gnu-emacs@gnu.org; Fri, 03 May 2019 07:52:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMWjk-0006De-Pf for help-gnu-emacs@gnu.org; Fri, 03 May 2019 07:52:22 -0400 Original-Received: from pv50p00im-zteg10021301.me.com ([17.58.6.46]:51888) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hMWjk-0006Cl-GD for help-gnu-emacs@gnu.org; Fri, 03 May 2019 07:52:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1556884339; bh=s4RbmiWrjC+kBgKNtBYV7Mhfwj7UlHjwaXrnk4csQqw=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=VvY/vVUTZfKT9PCi3gJgi/IYuAmsE/0Wmt6qaTrMwBghOI4NfGBwOmgpyiYYJqARX alUCiD4kp0QekxcLwPLil+26+iK7LhHWB5aVUTt7dpj0oMrGomZ8V3Gz8Ve4Ybdy1r 8yJklIa+h8/I3m65dbO27tHLaPN4iOATBwgKd5fbCUafvtFTF4rrsgvkMAQKipGnqF jhPH4UvCNauz0RrynnVjMj0gqZvwMqQQTvkg8OnYOK1oYd9fJM9iYcp1QaehINLTg+ Izr6Sc4nXTU2zYYX90shJ/xWqoGGQmfQBvKO0ry4bzK8U0YryIAgqnCumAs9JmVGve Ar8iBM/1gPenQ== Original-Received: from 172.20.nate.com (unknown [223.62.212.177]) by pv50p00im-zteg10021301.me.com (Postfix) with ESMTPSA id 57DEE580074; Fri, 3 May 2019 11:52:12 +0000 (UTC) In-Reply-To: <20190503103644.63lccjehmzulaojn@Ergus> X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-03_06:, , 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-1905030075 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 17.58.6.46 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:120167 Archived-At: >> 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. >>=20 > 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.=20 The difference between guile and CL is that * Guile is arguably not popular and not used by many programs.I=E2=80=99ve= never heard a program that is popular and uses guile as an extension = language. CL is, well, much popular than Guile, and is used by = industry-strength programs. * Guile (which is a scheme) has a radically different syntax with elisp = (which means that to implement elisp in guile, one has to hack the byte = code interpreter AFAIK). Elisp can be implemented inside CL with full = compatibility, which mitigates lots of problems between interfacing = between CL code and elisp code. * I=E2=80=99m pretty sure CL will be much, much faster than guile. CL = was optimized for about 30 years or so, and SBCL compiles CL all the way = to native code, which is comparable to C. I=E2=80=99m not sure if guile = can do that. >> 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????? >>=20 > maybe it has to do with this: >=20 > https://www.gnu.org/gnu/rms-lisp.en.html = I read the link; it=E2=80=99s a pity to not consider CL because it = isn=E2=80=99t =E2=80=98lispy=E2=80=99 enough.=20 >=20 >> IMHO building emacs on CL would be a wonderful idea... and would fix = many problems that current Emacs have. >>=20 > And create others, it is always a trade off. What problems would CL based Emacs can make?=CC=8A=CC=88 Can you show = some examples?=CC=8A=CC=88 I am genuinely interested. >=20 > Any way >=20 > 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. Well, CL is as fast as C=E2=80=A6.=20 >=20 >>> 2019. 5. 3. ?????? 9:44, Ergus ??????: >>>=20 >>> WARNING: This email has plenty of personal opinions. >>>=20 >>>> On Fri, May 03, 2019 at 08:39:43AM +0900, ????????? wrote: >>>>=20 >>>>> 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) >>>>=20 >>>> This, very much sounds like Guile Emacs. Anyone knows how Guile = Emacs >>>> is doing????? It???s very much looks like vaporware these days :-( >>>=20 >>> Yes, that is the dream (at least the closest we have ever been) >>>=20 >>>> Is upstream considering Guile Emacs as a valid solution? >>>=20 >>> 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 . >>>=20 >>> 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)) >>>=20 >>> 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 >>> ((())()'()). >>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> (Some time ago there was a lot of effort and time invested in = porting C >>> functions to Elisp in emacs) >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> [1] https://tromey.com/blog/?p=3D982 >>> [2] = https://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00393.html >>=20 >=20