From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: master 289000e: Merge branch 'feature/native-comp' into trunk Date: Mon, 26 Apr 2021 22:02:49 +0200 Message-ID: <875z08n79y.fsf@telefonica.net> References: <20210425182508.6CC7C2094D@vcs0.savannah.gnu.org> <831rayktot.fsf@gnu.org> <83v989jmuc.fsf@gnu.org> <83czuhjh0r.fsf@gnu.org> <87eeexm56d.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7314"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:cHJVFgeedz1spM7z7F4lBwXKdxY= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 26 22:04:02 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 1lb7Sc-0001oV-Fs for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Apr 2021 22:04:02 +0200 Original-Received: from localhost ([::1]:44952 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lb7Sb-0005jO-Hv for ged-emacs-devel@m.gmane-mx.org; Mon, 26 Apr 2021 16:04:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60036) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lb7Rc-0004ri-I9 for emacs-devel@gnu.org; Mon, 26 Apr 2021 16:03:00 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:46636) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lb7Ra-0007sK-Nz for emacs-devel@gnu.org; Mon, 26 Apr 2021 16:03:00 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lb7RW-0000cS-P5 for emacs-devel@gnu.org; Mon, 26 Apr 2021 22:02:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:268501 Archived-At: 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. 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) 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.