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: Enabling native compilation by default when libgccjit is present Date: Sun, 05 Dec 2021 21:55:25 +0100 Message-ID: <87ee6qbwle.fsf@telefonica.net> References: <83wnkm94oq.fsf@gnu.org> <87y251vdeh.fsf@gnus.org> <87lf11tlzf.fsf@gnus.org> <87r1atrsp9.fsf@gnus.org> <8735n85fa5.fsf@gnus.org> <87r1arskmq.fsf@gnus.org> <87r1arsjpu.fsf@yahoo.com> <87ilw3sjlr.fsf@gnus.org> <87r1ar4mi2.fsf@gmail.com> <874k7nw32n.fsf@gnus.jao.io> <87mtlfasg4.fsf@telefonica.net> <877dcix39b.fsf@gnus.jao.io> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3720"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:7UxEB9xvBlkxIWVeM2kfuHtorvU= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 05 21:56:33 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 1mtyYi-0000iJ-7X for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Dec 2021 21:56:32 +0100 Original-Received: from localhost ([::1]:59058 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mtyYg-0003as-8J for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Dec 2021 15:56:30 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40398) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtyXs-0002pY-JV for emacs-devel@gnu.org; Sun, 05 Dec 2021 15:55:40 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:33266) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mtyXq-0008CZ-Tn for emacs-devel@gnu.org; Sun, 05 Dec 2021 15:55:40 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1mtyXn-0009xL-D9 for emacs-devel@gnu.org; Sun, 05 Dec 2021 21:55:35 +0100 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.29 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:281027 Archived-At: "Jose A. Ortega Ruiz" writes: > On Sun, Dec 05 2021, Óscar Fuentes wrote: > >> The reason for this is not hard to understand for anyone with a little >> bit of knowledge about binary code optimization. For instance, if your >> Elisp code consists on invoking opaque C primitives, the gain of >> compiling it to machine instructions will be mostly irrelevant. > > Well, yes; i am pretty sure that if i went package by package and read > the code i use, the lack of speedups would most probably make sense; but > i find it curious that i am using so little "elisp-heavy" code, given > the variety of contexts in which i use emacs; somehow i was expecting > more what Arthur or Eli report, an overall improvement. Maybe i'm just > lucky in avoiding cpu intensive pure elisp code (i don't use lsp servers > either), or, more generally, optimizable elisp, and there's in fact a > noticeable effect for most heavy users. It is interesting that the > patterns can be so markedly different. There is a survivorship bias at play here. Code that was deemed slow on Elisp was implemented on C (and this is happening since machines were extremely slow compared to today's, so there are plenty of functions implemented in C that would make no difference on user experience if they were translated to Elisp nowadays.) Ironically, having so many functions on C makes nativecomp slow. In other cases Emacs resorted to external processes (or modules, more recently) to do the job. And then some projects were never implemented because Elisp performance is inadequate. So the result is that currently we have little Elisp code were nativecomp can theorically make a difference. More so when the metrics we use is U.I. responsiveness: projects that failed on that criteria never achieved popularity.