From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: master 289000e: Merge branch 'feature/native-comp' into trunk Date: Wed, 28 Apr 2021 14:07:14 +0000 Message-ID: References: <831rayktot.fsf@gnu.org> <83v989jmuc.fsf@gnu.org> <83czuhjh0r.fsf@gnu.org> <87eeexm56d.fsf@telefonica.net> <875z08n79y.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23128"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 28 16:08:40 2021 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 1lbkro-0005vr-IZ for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Apr 2021 16:08:40 +0200 Original-Received: from localhost ([::1]:56210 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lbkrn-0002NC-Ly for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Apr 2021 10:08:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38276) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lbkqV-0001iZ-Sj for emacs-devel@gnu.org; Wed, 28 Apr 2021 10:07:19 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:56464 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lbkqT-0005h9-Mh for emacs-devel@gnu.org; Wed, 28 Apr 2021 10:07:19 -0400 Original-Received: (qmail 76913 invoked by uid 3782); 28 Apr 2021 14:07:15 -0000 Original-Received: from acm.muc.de (p4fe15c50.dip0.t-ipconnect.de [79.225.92.80]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 28 Apr 2021 16:07:14 +0200 Original-Received: (qmail 10991 invoked by uid 1000); 28 Apr 2021 14:07:14 -0000 Content-Disposition: inline In-Reply-To: <875z08n79y.fsf@telefonica.net> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:268570 Archived-At: Hello, Óscar. On Mon, Apr 26, 2021 at 22:02:49 +0200, Óscar Fuentes wrote: > Alan Mackenzie writes: > >> C code is opaque to native-comp and puts a hard limit on how much it can > >> optimize Elisp. Thus I hope that in the future more and more code will > >> be moved from C to Elisp. > > Does that make sense? To move time critical code from fast C to slow > > Lisp, and then optimise it back, partly? > Calling C is a bit slow, but that's not the worst problem it introduces. > When a call to a C function is made, the native-comp optimizer must > throw away information it learned about the Elisp code it was compiling, > hence reducing optimization opportunities. Furthermore, the C function > must know how to many cases while only one or a few of them make sense > at any given call site. You're suggesting optimisation between Lisp functions. I'm sceptical about how much that could win. > Consider this extreme example: > (defun foo (x) > (+ x 12)) > (defun the-answer-p (x) > (or (and (stringp x) (string= x "42")) > (and (numberp x) (= x 42)) > (and (bufferp x) ... etc))) > (let ((a 30)) > (if (the-answer-p (foo a)) > (message "The answer is %d" (foo a)) > (message "We remain ignorant"))) > The optimizer knows that the argument passed to `foo' is `a', which > holds the constant `30'. It also knows that the value returned by `foo' > only depends on its argument, so it can simply replace those calls to > `foo' with (+ 30 12), and then with its result: 42. Then, on the call to > `the-answer-p', the optimizer knows that the argument is the numeric > constant 42, hence the second condition is true, so it can replace > `(the-answer-p (foo a))' with `true', and then colapse the `if' to just > (message "The answer is %d" 42) This sort of thing is surely untypical in Emacs. > If `foo' and `the-answer-p' were implemented on C, none of this > optimizations could be possible, because the optimizer would know > nothing about the inner workings of those functions. > I'm no Elisp expert, so the above might not fully translate to what is > achievable in practice by native-comp, but the general point holds. > >> And other areas can benefit too: one thing which IMO has lots of > >> potential is to native-compile regexps. > > Again, how would that work? Regexps are already handled in C. How > > could native compilation of Lisp add anything? > Not native compilation of Elisp, but native compilation of the regexps: > a function is generated that implements the regexp. Instead of passing > the regexp to the engine, the function is called. OK, I see what you mean, now. Currently, if I understand correctly, regexps are compiled into an interpreted language at runtime, and they are stored in a (fairly large) cache indexed by the regexp string. When would you compile the regexps into native code? For constant regexps this can be done at build time, but there are regexps constructed at run time in Emacs. This compilation of regexps at run time might negate the advantages in speed that the complation would otherwise bring. -- Alan Mackenzie (Nuremberg, Germany).