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: Sat, 4 May 2019 15:27:12 +0200 Message-ID: <20190504132712.n4n7d5lwmuu2nmlt@Ergus> References: <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> <87muk3b2ru.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="54073"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: help-gnu-emacs@gnu.org To: =?utf-8?B?w5NzY2Fy?= Fuentes Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat May 04 15:30:09 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 1hMujv-000DyP-UQ for geh-help-gnu-emacs@m.gmane.org; Sat, 04 May 2019 15:30:08 +0200 Original-Received: from localhost ([127.0.0.1]:56702 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMujt-0002sh-O4 for geh-help-gnu-emacs@m.gmane.org; Sat, 04 May 2019 09:30:05 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMuhF-00011S-BB for help-gnu-emacs@gnu.org; Sat, 04 May 2019 09:27:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMuhE-0008Vp-4L for help-gnu-emacs@gnu.org; Sat, 04 May 2019 09:27:21 -0400 Original-Received: from sonic303-20.consmr.mail.ir2.yahoo.com ([77.238.178.201]:37890) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hMuhD-0008Sq-Lm for help-gnu-emacs@gnu.org; Sat, 04 May 2019 09:27:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1556976436; bh=clNzDxDzQLW/OftPSRECEcSx6HR2QdnZ84Zrkzg/u/g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=GUJRkXT61PaTnMGkEVXx1T01NTksyfiABbWFkuvY29ZyKgImdV5YkWWr5ThQPLCaj3pi/N5DNo267JVOkru0jSA7zEUSkOVmDzbkkF2Z7sN8730Ebddgm6IYWOTxqfDGhw/ztwCq/HBqgdUPS9u4Zy+VuD8RUX14dgtZIUw1EMfRi/Qp/Fy+KWItPEV09RnjKIm2RhnzSkDwRmb8Ixb79NmmPquePc11OzUNnqmE+hIK0oQDXQ3WGucpmLodTBg7bs+Re4PphXNnc+tdaRZSqWLRbhuHM8A1EmyfIn3PcMCCCwxp+WEizs4KRFlq8bJ++wdfuXBtNEBGgQc7YVWtyg== X-YMail-OSG: E8R5J3IVM1lPVJ_R3FHbWi5O8.u3cepLMwJ.rOPjS6fT0TjSd_3Q.EofyE9kwYT HFiMi9p9.mYPLAkY_g46rLlY1SN3Dli9elkto5FZjMPSWhz9EJ_epTsh_s.H2MbWp48kAthUb15d ZW0EoFZkEqvQIzLmVuygopOp5xMZZbhqP1cptFral594pbUjDJ5sYMLSybqASo8IN4eF7j5db81J DXLe.pobez8mQNqz7k_jS_BfrZbOmDsCa.7Yt.6pFRorTXSF5jrPiu2n0bcbA3rKNLUlpnHHz5Ck aztccAHUK35EC47oMYuURfii.wMkujb_K1nlRhrd5DXKCOt3Vk2663UO7w188ESf0Wd9lvy.xrUO Kn.5Pl.FkHTVaOkSivqUOAvWqWjdGmM_zCF6IFW_oh0RacEKNgUhNfwIkB_epqjDBTmjq0M3Rs8V rAokvNVmI8ZXu7B1VIfBZpDdGRhDHz8eYNqXse8xVLNCyioVOjmolwcwXZ162EskfI2ZrP8A4mr. c0zf48zcEuqV1SXH0YsuaZIwtvgWUbqnVU3.p9Jnk_fwxRqGRu7ghud3AjMOLn6LFSiWnWebI.Up VNvXNrcL.d.5_jnV2bpkd2Yx39Oq1zLUsYu.qScekVhUKgW1yJ6cCyMGLcodQOy4ide7s.d4Ld2_ lRBh8_r5rGA8vjjW95r_FKOu7cgrBTlrfHjVT4BGbEd_mO1hPfO1qVelbVINAQg3ZaZkaW90DJWZ Ezapkbx0L4Cq3xJZpxsPavIr5U0sQhIL8cpFiY.X3o.ruxYrDA1ZiuzmZUO1iaWHpIx.opcJfYKJ ZwF240Ynojn0DV4H49.NU.81ngoYbZqc38UJtbtWun Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ir2.yahoo.com with HTTP; Sat, 4 May 2019 13:27:16 +0000 Original-Received: from 2.152.205.184.dyn.user.ono.com (EHLO Ergus) ([2.152.205.184]) by smtp419.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID bcf20fe51e82bb5e20a085cc3feb433b; Sat, 04 May 2019 13:27:15 +0000 (UTC) Content-Disposition: inline In-Reply-To: <87muk3b2ru.fsf@telefonica.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.238.178.201 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:120187 Archived-At: On Sat, May 04, 2019 at 12:18:29AM +0200, ?scar Fuentes wrote: >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. > That's true. The code quality will be not very good (as what happen in Android Java native compilers and Cython) but some of the optimizations in the low level can be applied. That depends of the optimizations implemented and the information provided to the compilers (both of them). A Lisp-C compiler for example can reduce significantly the function call overheads and callback overheads cause thanks to the Lisp syntax it is very easy to apply inline optimizations which in C represent a VERY important improvement. In your example code foo, setq and operator + are functions called in runtime, which interpreted means go to the symbol hashtable, find the pointer to the function, interpret the inputs and execute... compiling that... just think how it can change. With a simple optimization like having the hardcoded 10 the compiler will know the number of iterations to execute and the C compiler applies many good optimizations in those cases. SO it won't be the same than your second code, but performance could be in the same order in many cases.