From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: Is Elisp really that slow? Date: Sun, 12 May 2019 17:18:27 -0400 Message-ID: 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="191317"; 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 Sun May 12 23:33:57 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 1hPw6W-000nfO-FJ for geh-help-gnu-emacs@m.gmane.org; Sun, 12 May 2019 23:33:56 +0200 Original-Received: from localhost ([127.0.0.1]:47505 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPw6V-0004ze-Ds for geh-help-gnu-emacs@m.gmane.org; Sun, 12 May 2019 17:33:55 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPw5z-0004iH-E4 for help-gnu-emacs@gnu.org; Sun, 12 May 2019 17:33:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPvri-0007Zh-Sw for help-gnu-emacs@gnu.org; Sun, 12 May 2019 17:18:39 -0400 Original-Received: from [195.159.176.226] (port=33442 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hPvri-0007Uy-MH for help-gnu-emacs@gnu.org; Sun, 12 May 2019 17:18:38 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hPvrg-000Wo0-TR for help-gnu-emacs@gnu.org; Sun, 12 May 2019 23:18:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:ZBME1VLu1wyiicoYR66NYHG1GdM= 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:120328 Archived-At: > 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. 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 (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). 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). Stefan