From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: "Bringing GNU Emacs to Native Code" at the European Lisp Symposium Date: Sat, 02 May 2020 09:48:15 +0000 Message-ID: References: <69d8b48d-bd09-41c1-a89d-ed76fe0284a4@default> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="45423"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: stefan@marxist.se, drew.adams@oracle.com, emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 02 11:49:11 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jUoli-000Bio-RV for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 11:49:10 +0200 Original-Received: from localhost ([::1]:37010 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUolh-000693-Uv for ged-emacs-devel@m.gmane-mx.org; Sat, 02 May 2020 05:49:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40856) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jUokz-0005SD-Sy for emacs-devel@gnu.org; Sat, 02 May 2020 05:48:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jUokz-0005NL-Bb for emacs-devel@gnu.org; Sat, 02 May 2020 05:48:25 -0400 Original-Received: from mx.sdf.org ([205.166.94.20]:54602) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jUokw-0004ZU-QB; Sat, 02 May 2020 05:48:23 -0400 Original-Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 0429mGKZ028283 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 2 May 2020 09:48:16 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 0429mFCS010544; Sat, 2 May 2020 09:48:15 GMT In-Reply-To: (Richard Stallman's message of "Fri, 01 May 2020 22:27:55 -0400") Received-SPF: pass client-ip=205.166.94.20; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/02 05:48:16 X-ACL-Warn: Detected OS = ??? X-Received-From: 205.166.94.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:248389 Archived-At: Richard Stallman writes: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > We can always discuss the dynamic binding support but has also to be > > considered that the performance uplift is expected to be smaller for > > this. > > Such is life. But even if dynamic-default binding can't get the same > amount of speedup, it shoulod work correctly. No doubt. I realize I haven't explained my self very well: I'm sure it would work, what I'm not sure of is if is a good technical solution. > You might find a way to recognize that some bindings can't be seen by > any other functions, and treat them as lexical on the grounds that > doing so would not alter the result. This the point. I think we could at best make this assumption only on calls to C primitives (that we assume cannot be redefined) that are known to be side effect free and not to use global variable bindings in general. Any other call must have all variables spilled first. Given the frequency of calls and that almost all of these cannot be proved to target one function of this very specific class, I think one would end-up spilling almost always all variables anyway. I always thought this is one of the main reasons why lexical scope was introduced and I think this optimization is not worth being implemented. I believe that if there will be a speed-up compiling dynamic code this will come just from non having to decode byte-op-codes and manipulating the execution stack. In case the speed-up would come-up to be minimal imposing long compilation times for a compiler that is unable of optimizing much would be sad. OTOH I think no one as data on this speed-up. Given the discussed suspect of poor performance I intentionally left this task aside to work on more urgent tasks. Nothing prevents to have a try on this later if we think is really important. Andrea -- akrl@sdf.org