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: Why is Elisp slow? Date: Sat, 04 May 2019 00:18:29 +0200 Message-ID: <87muk3b2ru.fsf@telefonica.net> 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> <83ftpwnhsy.fsf@gnu.org> <20190503095847.5vmkwdwugrqyfj2g@Ergus> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="117674"; 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 Sat May 04 00:18:58 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 1hMgW7-000UOM-Tz for geh-help-gnu-emacs@m.gmane.org; Sat, 04 May 2019 00:18:56 +0200 Original-Received: from localhost ([127.0.0.1]:47909 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMgW6-0000qf-K4 for geh-help-gnu-emacs@m.gmane.org; Fri, 03 May 2019 18:18:54 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMgVs-0000qK-E3 for help-gnu-emacs@gnu.org; Fri, 03 May 2019 18:18:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMgVr-0002jT-Hn for help-gnu-emacs@gnu.org; Fri, 03 May 2019 18:18:40 -0400 Original-Received: from [195.159.176.226] (port=51302 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hMgVr-0002jC-BG for help-gnu-emacs@gnu.org; Fri, 03 May 2019 18:18:39 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hMgVo-000Tum-EL for help-gnu-emacs@gnu.org; Sat, 04 May 2019 00:18:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:JbucDH2v+NIFgjkoHqPvAAnJdEE= 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:120175 Archived-At: Ergus writes: >>More importantly, the libJIT build failed to show any significant >>speed-up wrt byte code, so it sounds like maybe the whole idea was >>either wrong or its design couldn't possibly provide any gains. Or >>maybe we just measured the speed-up in wrong scenarios. >> > This is not surprising. My work is 80% performance measurement and > benchmarking and the real improvements with JIT compilation (in my > experience) and specially with libJIT is not as good as many people > expect in most of the common scenarios. That's because the generated > code is usually very generic (so it does not take advantage of > architecture specific features), and strategies like vectorization and > branch prediction are very difficult to hint (most of the times > impossible). So the only real difference with a bytecode interpreter is > the bytecode parsing part, but not too much more. On Emacs case, I'm pretty sure whatever advantages comes from good architecture-specific code, accurate branch prediction, etc are below the noise level. As you pointed out below, Elisp is a dynamic language and for turning this (let ((acc 0)) (dotimes (i 10) (setq acc (+ acc (foo i))))) into this int acc = 0; for(int i = 0; i < 10; ++i) { acc += foo(i); } you need either sophisticated analysis (that, in practice, only works for the "easy" cases) or annotate the code with type declarations (and enforce then). Because otherwise handling variables as containers for generic values is incompatible with "C-like" performance. And an Elisp -> C translator does not magically solve this.