From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Should native compilation be enabled by default? Date: Fri, 08 Mar 2024 10:06:56 +0200 Message-ID: <86bk7p171b.fsf@gnu.org> References: <86sf19p0hw.fsf@gnu.org> <87a5ncfm1r.fsf@> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32458"; mail-complaints-to="usenet@ciao.gmane.io" Cc: bjorn.bidar@thaodan.de, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Mar 08 09:08:35 2024 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 1riVHP-0008Ed-JD for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Mar 2024 09:08:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1riVGU-0005ag-Pe; Fri, 08 Mar 2024 03:07:38 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1riVGT-0005aY-9M for emacs-devel@gnu.org; Fri, 08 Mar 2024 03:07:37 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1riVGS-0004hC-Hp; Fri, 08 Mar 2024 03:07:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Y01bApujAKmgfOr/g1lm2JQpXfHq6SP3K0N9fLOSHTU=; b=Om3W6Ik2dIdF zjS7tQAXW3FFqBmS3KDd5jrPZun2kfgnAUe+XjL6l9HFAc0APH3YuxFbcUbH0sEqFLMErFQNue85j 0t59Ky7aio+MX0bBw6RJxjrNmcG7uXLf8zXlWKh4ROg0ogVlMnE3TyycYk5xE8lc3THu0nl69f9jD VvB5VaS2KWxwj8TkBfgNGm+XYnR+vJb4+mdJnI+G/V+P1KPdRKnFtwoUULRPGjdKyIrUKQhp9WuoN flPACdr1k12yg7yQfQdA4WFA5VStp6RjQeYJ8rNoYeM5e8iJ/tnQ2sP9TbHb0fFK2FaeH9ULV4B0y Z9+wG8TP58GTdDtiD9shBQ==; In-Reply-To: (message from Richard Stallman on Thu, 07 Mar 2024 21:29:29 -0500) 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:316889 Archived-At: > From: Richard Stallman > Cc: eliz@gnu.org, emacs-devel@gnu.org > Date: Thu, 07 Mar 2024 21:29:29 -0500 > > The best trade-off could be to mark some individual source files as > worth-while for native compilation, and by default do native compilation > only for those. While ideally true, in practice this would be a significant maintenance burden. The initial research of whether a given file can benefit from native compilation enough to justify it is already a large job, even just for files that are part of Emacs, because the actual gains depend on the functions used and the use patterns, which can and do vary widely. Then the results of this initial research should be somehow kept up-to-date as the Lisp code changes and also as libgccjit and GCC in general becomes a better compiler that can optimize better. So instead, we take an opportunistic way forward that is much easier maintenance-wise: we require native compilation to never produce much worse results than byte-compiled code would. We also require native compilation to produce code that is on average faster than byte-compiled code. This way, we don't have to worry about file-local issues unless the native code is significantly slower, in which case we ask users to report a bug, which we can investigate and solve. I believe this is similar to how optimizations are introduced into a compiler. In particular, no one suggests that each individual source file be tagged with the optimizations that produce significant gains for that file. However, as exception, a given source file can be tagged with optimizations that should or should not be done for it. We support similar features for native compilation: the no-native-compile cookie and the various native-comp-* variables that can be set in file-local variables to control the aspects of native compilation and optimizations for those exceptional files. So I think we have a reasonably good arrangement, both on average and where specific exceptional cases need special handling, and we do that in a way that doesn't present any significant maintenance burden.