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: Is Elisp really that slow? (was: Why is Elisp slow?) Date: Sun, 12 May 2019 18:46:20 +0900 Message-ID: <346107E9-590D-4A18-9152-ECFF36FC4EDC@icloud.com> 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> 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="135003"; mail-complaints-to="usenet@blaine.gmane.org" Cc: help-gnu-emacs@gnu.org To: tomas@tuxteam.de Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun May 12 11:46:43 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 1hPl46-000Z1K-J9 for geh-help-gnu-emacs@m.gmane.org; Sun, 12 May 2019 11:46:42 +0200 Original-Received: from localhost ([127.0.0.1]:41090 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPl45-0006m1-E4 for geh-help-gnu-emacs@m.gmane.org; Sun, 12 May 2019 05:46:41 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47036) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPl3r-0006lu-HE for help-gnu-emacs@gnu.org; Sun, 12 May 2019 05:46:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPl3q-0007oh-5X for help-gnu-emacs@gnu.org; Sun, 12 May 2019 05:46:27 -0400 Original-Received: from pv50p00im-ztdg10022001.me.com ([17.58.6.58]:54820) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hPl3p-0007nX-Tj for help-gnu-emacs@gnu.org; Sun, 12 May 2019 05:46:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1557654383; bh=6wBVx/cty/LkJLUVIYw/ivLE8rPI3UdkK3umX1NEYfg=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=YPusoNxF7CsOjdzy24L9Kqrdn6KqylXvJ1Kgj8xoynqNCx0jg3ViYrtTCGQ1SmrP9 Fe80Q7fVSr3bJ5x5LRZyFSuabQqhmGMVAdcyC8hMHu5IQMHSeGTBI+MkyEW5uCjovT 7xZ3urbdkSsOze2mjaWtiSeoJd1+CL10PPN0t/v/IUzPsAiMdTGPweX6H7N94PvJTb S9ZFZLuspDEziXrW2g5ARuYtfno1mzzA1T81JLUdHJRrGgFx+qi4Ke7g/IFvHjOB8y KuI1ntOmVTeY38bnun/7tNoFlY6bexyyRwLLqmJIDqakoja9HiYHeIAU+uY9mXfXQt b5PlT3S8tKBIA== Original-Received: from [192.168.0.15] (unknown [59.10.74.80]) by pv50p00im-ztdg10022001.me.com (Postfix) with ESMTPSA id 016EDA067F; Sun, 12 May 2019 09:46:22 +0000 (UTC) X-Mailer: iPhone Mail (16E227) In-Reply-To: <20190512075448.GA11650@tuxteam.de> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-12_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=308 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1905120074 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 17.58.6.58 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:120314 Archived-At: 2019. 5. 12. =EC=98=A4=ED=9B=84 4:54, tomas@tuxteam.de =EC=9E=91=EC=84=B1: >> On Sun, May 12, 2019 at 01:09:09AM +0200, Emanuel Berg wrote: >> tomas wrote: >>=20 >>> Show us the benchmarks. >>=20 >> How do people do benchmarks when it comes to >> comparing the speed of different >> computer languages? >=20 > My favourite search engine recommends [1], [2]. >=20 >> Do you solve a wide/varied set of problems (the >> same set) with different languages and then >> compare the wall clock execution time? >=20 > More or less, yes. See references. >=20 >> Perhaps using an atomic clock in >> a sterile environment? >=20 > Clock accuracy/precision/resolution will be the least of your problems > in a cross-language benchmark. Different languages exist for a reason, > and carry with them a whole set of different cultures, so they'll tend > to express a problem in subtly different way (leading to subtly differing > semantics). How do you account for the fact that some problem expressed > in C won't do array bounds checking, while in Java it will do them > dynamically all the time (costing runtime), whereas in some smart > functional language the compiler will do most of that work most of > the time, due to advanced compiler magic? How do you account for the > fact that in language A the programmer will take 100 times longer to > master the language, but one-tenth of the time to write a program? > The fact that this compiler will produce runtimes twice as fast, but > ten times as fat, and take 50 times the compile time? So, you would compare languages that are =E2=80=98safe and dynamic enough=E2= =80=99 as Elisp. E.g. Python, JS, CL, Ruby, etc. > Yeah. Numbers for illustration only. >=20 >> Now, while that would be interesting to do, >> I think it's pretty clear Elisp would benefit >> from more speed. >=20 > My whole point is that this is /not/ so clear. Emphatically so. > Speed comes at a price (did you do your research about Spectre > and Meltdown?). Perhaps Elisp has found an optimum in this tradeoff, > for the job it's supposed to do. Speed comes at a price, but as we see Pypy, JS, CL, and other high languages= that are fast, we can see that it is /so/ clear that we can pursue more spe= ed without sacrificing the language=E2=80=99s expressiveness, dynamicness, e= tc. > Well, actually this optimum point shifts around with time, since > the environment Emacs lives in changes (people using it, the kind > of tasks it is put to, but also the hardware it lives on). >=20 > Actually I'm convinced Emacs is tracking this optimum pretty nicely, > since it is looking back to 34 years of life (and still receives a > steady stream of patches [3]!). Few pieces of software can say that > of them. Well, look at Atom and VS Code which is using the V8 engine (through node) t= o execute JS to tweak the editor.=20 Now compare that to Emacs. And Atom gets criticized by it=E2=80=99s slow bootup time, etc... It=E2=80=99s pretty sure Emacs can benefit from some speed... >> Maybe it is not slow for its >> purposes, >=20 > ...and that is exactly the point! >=20 >> but it ain't fast either, sure is >> my impression. >=20 > I haven't the time currently to illustrate my point more, sorry. Do > your experiments, find out for yourself. >=20 > Cheers >=20 > [1] https://en.wikipedia.org/wiki/The_Computer_Language_Benchmarks_Game > [2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/ > [3] http://git.savannah.gnu.org/cgit/emacs.git >=20 > -- tom=C3=A1s