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: Tue, 7 May 2019 20:51:27 +0900 Message-ID: <44A389B2-9D9D-4C1F-B9E3-9859C77DAF70@icloud.com> References: <831BD780-F954-4E23-BF31-ED4E135C919B@icloud.com> <20190506125848.okei2qrib7m5p3vx@Ergus> <20190506161757.wg4wy3vr7emxnciv@Ergus> <443E6AB4-2478-4677-8A23-A0B04559E949@icloud.com> <84F2860D-523D-4F30-BD52-D6A915416167@icloud.com> <20190507104945.gfdrftaeztrzbkt6@Ergus> Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) 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="263789"; mail-complaints-to="usenet@blaine.gmane.org" Cc: help-gnu-emacs@gnu.org, Stefan Monnier To: Ergus Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue May 07 13:51:56 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 1hNydX-0016Lr-FE for geh-help-gnu-emacs@m.gmane.org; Tue, 07 May 2019 13:51:55 +0200 Original-Received: from localhost ([127.0.0.1]:45116 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNydW-0005Xt-BJ for geh-help-gnu-emacs@m.gmane.org; Tue, 07 May 2019 07:51:54 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43192) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNydE-0005Xd-Jp for help-gnu-emacs@gnu.org; Tue, 07 May 2019 07:51:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hNydC-00072t-MU for help-gnu-emacs@gnu.org; Tue, 07 May 2019 07:51:36 -0400 Original-Received: from pv50p00im-ztdg10011901.me.com ([17.58.6.50]:51802) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hNydC-00072N-Do for help-gnu-emacs@gnu.org; Tue, 07 May 2019 07:51:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1557229892; bh=/g9WU0kZ6qwDzZo0CmK0jLlNkdmmP+g/AcnUsgLyN4s=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=jhRmP+aqRbA+y/1tomb1guN5HNkxKvJGD38JEZePtZTl5cRMC6SIaMuUhYQsvPws7 Ksz7UQN/lsE2dfEPgapfNCO39rQaidTxVIVlq+5JCr3xNhSbAmq5j86pr3yZtQkjU/ sYvY92T+HOUJV5TNJNnH99RZaem8g650PWMP8DiA4MnglAOaeRxeX8uXUXGUPzKdNb OUPRXmoEXk/jfSBDUWZ49LZslIa95ETcMoEZ3tt/+AsXY03wVLtyQ2ziCvnVaS/80Z kj04PSOGnYa+DIlvMigynukvfVkX26g6CUJeDCLWuKDtLnueXCYsWew3taigkEdRP+ JuGcIB+aYylVg== Original-Received: from [10.56.218.59] (unknown [128.134.203.66]) by pv50p00im-ztdg10011901.me.com (Postfix) with ESMTPSA id 17114800460; Tue, 7 May 2019 11:51:30 +0000 (UTC) In-Reply-To: <20190507104945.gfdrftaeztrzbkt6@Ergus> X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-07_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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1905070078 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 17.58.6.50 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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:120250 Archived-At: > 2019. 5. 7. =EC=98=A4=ED=9B=84 7:49, Ergus =EC=9E=91=EC= =84=B1: >=20 > Hi all: >=20 > After reading the whole SBCL manual and the internals I have some > comments maybe useful if we decide to go in that direction. (If some = of > the core developers starts with this I will be very pleased to work on > that, but I am too new in emacs development to start it myself alone.) >=20 > 1) + Portability does not seems to be a big issue, they already = support > our architectures (and some extra) and they are putting a lot of = effort > on that. There is work to do, but in general, they already have what = we > need from Common Lisp. >=20 > 2) + They have documented how to port SBCL to new architectures, and = some > of the optimizations they implement, so, if we have a compiler > specialist on board and finally our developers choose not to go for > SBCL, then maybe some of those optimization could be considered for = our > Elisp compiler. >=20 > 3) - There is not C binding for SBCL. To extend it, there is not a > public-documented API and their approach is wrapping the C functions > from Lisp (FFI). I wrote in their mailing list and they redirected me = to > the CFFI page. >=20 > + The only advantage (I see) in this approach is that as CFFI has > been ported to almost all common list compilers/interpreters; if we > go in that direction for our C code we could potentially use any of > those and jump from one to another at configuration time. So we > don't have this problem (of being stock with a "bad" compiler) > anymore. > =20 > - The overhead produced by wrapping in the high level instead of the > low level in my experience (python, ruby, Julia) is usually much > higher than having C bindings.=20 > - Writing wrappers in lisp for all our C functions exposed to Lisp I > think is not an option if we don't create an automatic method. So > if no one creates a plugin for sbcl to support Elisp, I really > doubt the feasibility of using SBCL except if many of our current > core developers agree on that and join effort for that. Else it > will happen as with guile. There is an automatic method of generating C FFI bindings from header = files. See https://github.com/rpav/cl-autowrap = :-) What I was thinking about using CL to support Elisp is to define a new namespace for symbols (which, in CL terms, is a so-called =E2=80=98package= =E2=80=99) named =E2=80=98elisp=E2=80=99. All Cl-needed functions/macros are defined in the =E2=80=98cl=E2=80=99 = package, which means that you can call any cl function/macro by prefixing =E2=80=98cl:=E2=80=99 in the =E2=80=98elisp=E2=80=99 package. As CL and Elisp has many common things (such as the similarity of many, many macros like =E2=80=98defun=E2=80=99 or =E2=80=98defvar=E2=80=99= , etc=E2=80=A6 or that it is a Lisp-2), we can implement elisp entirely inside CL itself. No need for developing a plugin specially for SBCL; any CL = implementation will do. For functions defined in C, we can make or generate wrappers to get passed-in-arguments and dynamically wrap values into a Lisp_Obj C struct (AFAIU all lisp objects are represented as a struct of type info and = some pointers, am I right?) and call the underlying function generated by cl-autowrap. > 4) + With FFI as they implemented, it will be pretty easy to interface > and call C libraries and functions without needing a C wrapper to = expose > it to lisp, so maybe an important part of our C code could be > substituted with Lisp (simpler and smaller) glue code. But also we = will > be allowed to use C dynamic libraries directly without all the modules > complexity. (Somehow I feel that not everyone will like that if we > comment it in the developers mailing list :p ). >=20 > On Mon, May 06, 2019 at 02:47:12PM -0400, Stefan Monnier wrote: >>>> [ IIUC of the 4 cases above, at most 2 run the same version, so = we'd >>>> need to make sure the same Emacs version can be compiled against = all >>>> of those versions. No idea if it would impose a significant extra >>>> burden or not, but it's something to be considered. Also the fact >>>> that the latest release doesn't work on all those platforms is = rather >>>> worrying. ] >>>=20 >>> Hmm? I can't understand :-( >>> Why can't Emacs can include a specific version of SBCL's source = (e.g. as >>> a git module) and compile them all together? >>=20 >> Exactly because the version that can run on ARM is not the same as = the >> one that can run under Windows, which is not the same as the one that >> runs under AMD64. >>=20 >> Of course, maybe I'm confused by the table of available binaries (at >> http://sbcl.org/platform-table.html), and in reality the latest = version >> works fine on all supported platforms. >>=20 >> Stefan >>=20 >=20