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: Sat, 4 May 2019 22:38:25 +0900 Message-ID: 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> <20190504132712.n4n7d5lwmuu2nmlt@Ergus> Mime-Version: 1.0 (1.0) 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="102421"; mail-complaints-to="usenet@blaine.gmane.org" Cc: =?utf-8?Q?=C3=93scar_Fuentes?= , help-gnu-emacs@gnu.org To: Ergus Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat May 04 15:41:14 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 1hMuue-000QXK-Dy for geh-help-gnu-emacs@m.gmane.org; Sat, 04 May 2019 15:41:12 +0200 Original-Received: from localhost ([127.0.0.1]:56877 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMuud-0007mO-CM for geh-help-gnu-emacs@m.gmane.org; Sat, 04 May 2019 09:41:11 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42348) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMus8-0006F3-2r for help-gnu-emacs@gnu.org; Sat, 04 May 2019 09:38:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hMus6-0007KJ-W7 for help-gnu-emacs@gnu.org; Sat, 04 May 2019 09:38:36 -0400 Original-Received: from pv50p00im-ztdg10011901.me.com ([17.58.6.50]:53399) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hMus6-0007Is-Nf for help-gnu-emacs@gnu.org; Sat, 04 May 2019 09:38:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1556977109; bh=n1+b4L/fBBchvyQIsP1GZkDbzLVWRJeXL/dMZrEugVE=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=e2tdUVuKInmRIYQaXCbKMdLLJHmp20r/+0DpVBE34/Yobdt4rnoeQYONBturhhKol BeOBZlkOx3lFnlo2x+yFsnqpEb55cMX5XKYIj9uqlxmwNnfcV/cweGmyA5j/S64jQS 1wdNDxQh4TwV0wsZJN5W17I3TkGeLdPns7LJGci14qNHRbi8U9VY9DIVdkaJ3VyxDb u4iC8/OsUVV7X4psf616pdRhZCUZEj6pj7KChKtYgcYAzajNTNIMxSYfkOLbJXX9e5 LIZkThVYWiSaemT5ut8ykm+H8iTaJRbYyiaOrkYzMYfTtXMbQKYwNnLOndNZdrJBiD x0Iz/BU2R/9NQ== Original-Received: from [172.30.1.60] (unknown [211.192.227.198]) by pv50p00im-ztdg10011901.me.com (Postfix) with ESMTPSA id 415F3800186; Sat, 4 May 2019 13:38:28 +0000 (UTC) X-Mailer: iPhone Mail (16E227) In-Reply-To: <20190504132712.n4n7d5lwmuu2nmlt@Ergus> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-04_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=877 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1905040090 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 17.58.6.50 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:120189 Archived-At: 2019. 5. 4. =EC=98=A4=ED=9B=84 10:27, Ergus =EC=9E=91=EC=84= =B1: >> On Sat, May 04, 2019 at 12:18:29AM +0200, ?scar Fuentes wrote: >> Ergus writes: >>=20 >>>> 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. >>>>=20 >>> 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. >>=20 >> 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 >>=20 >> (let ((acc 0)) >> (dotimes (i 10) >> (setq acc (+ acc (foo i))))) >>=20 >> into this >>=20 >> int acc =3D 0; >> for(int i =3D 0; i < 10; ++i) { >> acc +=3D foo(i); >> } >>=20 >> you need either sophisticated analysis (that, in practice, only works >> for the "easy" cases) or annotate the code with type declarations (and >> enforce then). >>=20 >> Because otherwise handling variables as containers for generic values is >> incompatible with "C-like" performance. >>=20 >> And an Elisp -> C translator does not magically solve this. >>=20 > 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). >=20 > 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. I=E2=80=99m pretty sure that it is hard to do that, because lisp is a dynami= c language, and it is hard to be sure if that function I(the compiler) wants= to inline is really the function that the code writer wants to call. The transpiled code essentially will be C code that contains a small embedde= d elisp interpreter, which imposes the same overhead as running elisp code t= hrough the elisp engine from Emacs. > 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. Transpiled C code will have the same overhead. >=20 > 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. >=20 > SO it won't be the same than your second code, but performance could be > in the same order in many cases.