From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.help Subject: Re: Is Elisp really that slow? Date: Mon, 13 May 2019 00:22:02 +0200 Message-ID: <871s13uxdh.fsf@telefonica.net> References: <20190502214006.4fdsinp7u5xuqvdv@Ergus> <20190503004416.xfuzzucflp6bxpuz@Ergus> <8736lm30lz.fsf@web.de> <864l61j04d.fsf@zoho.eu> <20190511073254.GB29829@tuxteam.de> <04187AB9-AD7D-492D-A890-BCB01848370C@icloud.com> <20190511075712.GD29829@tuxteam.de> <86a7fsfv1m.fsf@zoho.eu> <20190512075448.GA11650@tuxteam.de> <346107E9-590D-4A18-9152-ECFF36FC4EDC@icloud.com> <83r293bvok.fsf@gnu.org> <87ef53vihw.fsf@telefonica.net> <83mujrbsk7.fsf@gnu.org> <87a7frvfo1.fsf@telefonica.net> <83h89zbndc.fsf@gnu.org> <875zqfv7sb.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="166249"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon May 13 00:34:22 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 1hPx2y-000h9Q-Hi for geh-help-gnu-emacs@m.gmane.org; Mon, 13 May 2019 00:34:20 +0200 Original-Received: from localhost ([127.0.0.1]:48024 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPx2x-00088a-HL for geh-help-gnu-emacs@m.gmane.org; Sun, 12 May 2019 18:34:19 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:35441) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPx1q-0007LF-Uf for help-gnu-emacs@gnu.org; Sun, 12 May 2019 18:33:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPwrF-0006x6-1P for help-gnu-emacs@gnu.org; Sun, 12 May 2019 18:22:14 -0400 Original-Received: from [195.159.176.226] (port=42902 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hPwrE-0006iv-R5 for help-gnu-emacs@gnu.org; Sun, 12 May 2019 18:22:12 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hPwrA-000UJF-OG for help-gnu-emacs@gnu.org; Mon, 13 May 2019 00:22:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:gYyOM4Vs2n9/TnwX5BhgmjQZ3xU= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:120329 Archived-At: Stefan Monnier writes: >> I have on my to-do list for this year to grab Tromey's JIT branch and >> migrate it to LLVM and see what the optimization passes can squeeze, >> possibly with some simple static analysis and, if I'm in the mood, type >> annotations on Elisp code. > > Elisp's current implementation is sufficiently naive that it should be > "easy" to make it significantly faster at least on some problems. I'm not interested on making Elisp 30% faster. I want something that can replace C for most purposes. > This said, it's also easy to overlook the fact that in most > circumstances time is spent running within functions implemented in > C and no amount of clever compilation will help Exactly. Elisp acts as glue code for the C base. This plus the fact that many elisp primitives reduce to calls to C functions explains the observed lack of impact of the JIT. >(and clever compilation > can easily end up counterproductive because we spend a lot of resources > (heap space, CPU time, you name it) trying to optimize code that's > largely irrelevant, so the end result is slower startup and no speedup, > or worse). Agreed. > If you want to do a JIT thingy that speeds up Elisp "in general" then > you need to make sure it does a good job eliminating redundant type > checks and things like that. You'll probably easily get good speed ups > for the usual tight loops this way. I encourage people to try something > like basic block versioning for that. > > But I'm not sure such a "faster Elisp" will make a big difference to the > kind of code one can write in Elisp. More specifically, I think it'll > take a lot of effort for a JIT to be good enough that we can implement > the json printer/parser in Elisp instead of C. > > So another alternative is to make it possible to write "Elisp-ish" code > that's specifically tailored for compilation to efficient code and > that's specifically marked as such. This has 2 very significant > advantages: > - the compiler can take its time because it's only applied to those > specific cases where we (presumably) know it's worthwhile. We may > even run the compiler ahead of time rather than in a JIT fashion so it > doesn't impact startup. > - the compiler doesn't need to accept all Elisp code and reproduce all > its intricate details faithfully. It can even signal errors and burp > on some constructs that it doesn't want to support. > Then again, maybe this "Elisp-ish" could be fairly far removed > from Elisp. E.g. it could even be plain old C (tho something in > between is likely more interesting). I've been advocating this Elisp-ish C for a long time. Even on your stint as maintainer I offered my implementation of my own C-with-sexps language. I'm interested on islotating certain parts of Elisp, add some stuff to help the optimizers and feed it to LLVM. Ideally, an Elisp hacker working within those limits could implement some cpu-intensive code that would perform similar to C with minimal retraining. At the same time, the language must retain enough expressiveness to bring significant advantages on development over C. defmacro is a must.