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: Sat, 11 May 2019 16:42:44 +0900 Message-ID: <04187AB9-AD7D-492D-A890-BCB01848370C@icloud.com> References: <87woj8bqho.fsf@telefonica.net> <83tvecocvv.fsf@gnu.org> <87sgtwboot.fsf@telefonica.net> <83muk4obfd.fsf@gnu.org> <20190502214006.4fdsinp7u5xuqvdv@Ergus> <20190503004416.xfuzzucflp6bxpuz@Ergus> <8736lm30lz.fsf@web.de> <864l61j04d.fsf@zoho.eu> <20190511073254.GB29829@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="178821"; 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 Sat May 11 09:43:19 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 1hPMf2-000kBt-0W for geh-help-gnu-emacs@m.gmane.org; Sat, 11 May 2019 09:43:12 +0200 Original-Received: from localhost ([127.0.0.1]:55582 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPMf1-0000v9-0M for geh-help-gnu-emacs@m.gmane.org; Sat, 11 May 2019 03:43:11 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPMeh-0000ti-LK for help-gnu-emacs@gnu.org; Sat, 11 May 2019 03:42:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPMeg-0005gu-Fb for help-gnu-emacs@gnu.org; Sat, 11 May 2019 03:42:51 -0400 Original-Received: from pv50p00im-ztdg10021201.me.com ([17.58.6.45]:39065) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hPMeg-0005gU-6q for help-gnu-emacs@gnu.org; Sat, 11 May 2019 03:42:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1557560569; bh=5k4JYfFDMSima0Lh2l00SW9JHJN7ZnUWsOX6R8avyQk=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=oyBn8VJnFYY+pO3a3L+G+1EcaOq1m+UVt+VXkChYQCDcJwlAmnsQ1kVzeUrXFHMdc U1ai12hOKthPH0qovO6HioREEi9mc6WgH1zPdYpyQsKu+xQ4nSrk4MLDntXaZuy2Yi cpmfS5dro2oLDO+jXw4OmugLd5/4qf8nQJDEhK+pAMDIgwm7MdlMSUjcEXfB6Y25l+ rM2YTzXXitJpxGqTVeSlXZx6Xp71galShub9+IL8AtoBMa5gX+9w8m1J4WN0+OKy1w bWsqkJnZKW2TmgSYuECzkhrdInqQM6Pi0pG34WE9aT1YsxsI5UgkKs7IlI9CnzJ8co XqwSSr8MycAVA== Original-Received: from [10.129.64.174] (unknown [223.38.30.158]) by pv50p00im-ztdg10021201.me.com (Postfix) with ESMTPSA id C8640A404F5; Sat, 11 May 2019 07:42:48 +0000 (UTC) X-Mailer: iPhone Mail (16E227) In-Reply-To: <20190511073254.GB29829@tuxteam.de> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-11_05:, , 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1905110053 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 17.58.6.45 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:120298 Archived-At: I understand your points; but IMHO Elisp is not doing well in all kinds of a= spects, Isn=E2=80=99t it?=CC=8A=CC=88 =EB=82=98=EC=9D=98 iPhone=EC=97=90=EC=84=9C =EB=B3=B4=EB=83=84 2019. 5. 11. =EC=98=A4=ED=9B=84 4:32, tomas@tuxteam.de =EC=9E=91=EC=84=B1: >> On Sat, May 11, 2019 at 02:38:58AM +0200, Emanuel Berg wrote: >> If it is possible to have Elisp as fast as CL >> or even as fast as C (!), the only problem is >> no one has been motivated to do it! ??? >>=20 >> Are there not young people and university >> students who would love such a challenge? >=20 > One last attempt: this whole thread is based on the premise > that there is one clear definition of slow. Yet, there isn't. >=20 > Back in the 1980s, the (micro-) computers were so slow, that > access to main memory wasn't a problem at all. I know of one > design where two Z80 ran off the same static RAM, taking turns > to access it. >=20 > Somewhat later, RAM was so slow that we had to interpose several > layers of cache between it and the CPU (that is still the situation > nowadays, which brought upon us Meltdown and Spectre). >=20 > A tad later, CPUs stopped getting faster at sequential execution. > Making pipelines deeper and things stopped being fun, and transistors > are at the current limit of how fast they can do. But, we can make > them cheaper and smaller (and perhaps somewhat less greedy on > electrons), so packing more CPUs on the chip is becoming more > fashionable [1]. >=20 > If you want to be really fast these days, you have a gang of > fairly dumb processors all doing the same instruction at a > time (SIMD). It's weird to program that: if you take a branch, > you have to decide for one side, and throw away those members > of your gang which went the other way (well, you throw their > results away, actually). Perhaps pick the second branch up > in a second pass. >=20 > Of course, the definition of "fast software" changes radically > when your bedrock moves that quickly. The second "generation" > above made cache-efficient algorithms interesting (somehow > a rebirth of the 70ies, where you had very limited RAM and > somewhat bigger external memory). In the third generation, > parallelizable algorithms became more interesting (did you > know that bubble sort, the laughing stock of CS, parallelizes > pretty well? If you have more processors than time, this one > isn't that bad). The fourth generation... well. Interestingly, > functional languages help in making fast programs for those > strange beasts without getting crazy. >=20 > What I don't like about this thread is that "fast" is being > treated as the only metrics (it isn't) and as if it were a > metrics at all (it isn't either). >=20 > Cheers >=20 > [1] Sometimes you see that coming and bet too early on it. > Alas, Sun is no more: > https://en.wikipedia.org/wiki/Sun_Niagara=20 >=20 > -- tom=C3=A1s