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: Suppressing native compilation (short and long term) Date: Thu, 13 Oct 2022 08:46:01 +0300 Message-ID: <835ygob7ja.fsf@gnu.org> References: <87ill8paw7.fsf@trouble.defaultvalue.org> <83o7uzivey.fsf@gnu.org> <3ac9d2b9632f75018327a1bcde0c373f152c404a.camel@gmail.com> 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="25726"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rlb@defaultvalue.org, emacs-devel@gnu.org To: Liliana Marie Prikler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 13 07:49:37 2022 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 1oir68-0006Xe-86 for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Oct 2022 07:49:36 +0200 Original-Received: from localhost ([::1]:55926 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oir67-0003G2-0E for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Oct 2022 01:49:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52390) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oir2U-00018w-HY for emacs-devel@gnu.org; Thu, 13 Oct 2022 01:45:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:56824) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oir2U-00059E-2B; Thu, 13 Oct 2022 01:45:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=1jBFOHiFJUx2OsyjGYBqj4jJU6WopawrE28h3Ldv+eE=; b=pkeFONXryGeBbiwaNoNx 8imC47KIeh3UL5FdupD4BQ23FYLy5r7LWiLcXnS3P59bitoKSts2yyVMjvKxYVObfMB4RUJ7cOyus pOulOF80Mi2v3kpUKRnQ6+Su6aWukaL8+U7ICxQuUYkok4F8eRB/L/Yp/AGxo2vMliFKb/CwVq0p2 VKloveB8iFGHFwovsi9PhXSmNVzcnVxPN3FbJ5Ag/1Nw/hWhDqXMHhzuX5pFXJ5Gqlpta49nT4Egm rHo8djjaSgvyqmWj3Zws+4ZEqFge1rx32+yMKXU9ubkC17vkx62Ar/FnaWTid14ddCXnILgjSxeAT qcpGA0mpYENq6Q==; Original-Received: from [87.69.77.57] (port=4790 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oir2S-00016r-FD; Thu, 13 Oct 2022 01:45:48 -0400 In-Reply-To: <3ac9d2b9632f75018327a1bcde0c373f152c404a.camel@gmail.com> (message from Liliana Marie Prikler on Wed, 12 Oct 2022 22:22:46 +0200) 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:297653 Archived-At: > From: Liliana Marie Prikler > Cc: emacs-devel@gnu.org > Date: Wed, 12 Oct 2022 22:22:46 +0200 > > In GNU Guix, we observe certain packages breaking when trying to > compile them natively. While some of that is on us for messing up the > package descriptions, one could also encounter genuine bugs in native > compilation that one wants to work around by disabling it. When you encounter bugs in native compilation, please report them to us, so we could fix them. As of now, we are not aware of any such bugs that were reported and haven't been fixed. So if you still have such problem, please report them ASAP. > (For added > trouble, whether or not your package breaks could depend on the CPU due > to being *native* compilation; thus the "no-native-compile" local > variable is insufficient to address this generally.) Why isn't it sufficient to use no-native-compile? It just means that on some architectures the corresponding file will be loaded as byte-compiled, and thus will be slightly slower (how much slower depends on the code, so if you are worried, my recommendation is first to measure the difference -- you might be surprised). In any case, if no-native-compile doesn't for some reason solve the problem, I don't understand how disabling native compilation will: the latter is a more blunt instrument than the former, e.g., it cannot be applied on the per-file resolution. > In GNU Guix, we default to not compiling packages ahead-of-time, > instead using a minimal emacs that can only do byte compilation for > most packages. Users can however pretty easily switch to ahead-of-time > compilation by swapping out the emacs package (using what Guix calls > package transformations). This is also important because apart from > the current Emacs we typically provide an emacs-next package for > upcoming versions, as well as some other variants that the user might > want to use instead. Again, we assume that users who want to opt in to > native compilation do so via a transformation. Sorry, I'm unfamiliar with this terminology. When you say "ahead-of-time compilation", do you mean native compilation of all the Lisp files before they are loaded for the first time? Or do you mean something else? And what is "swapping out the emacs package", and what is "package transformation"? > In this context, the default of compiling everything that has hitherto > only been byte-compiled is an ill-advised choice. Now, there is a > chance that the user meant to do this anyway, but I think they rather > a) use whatever the distro default is without caring either way or b) > actually didn't want this package natively compiled. Due to some > packages breaking, we had a lot of b) in our mailing lists in the past > few days. If a package is a single file or a small number of files, those users can add the no-native-compile cookies in those files. And again, disabling native compilation is a method that doesn't allow them fine-tuning anyway, so I fail to see how it could help them here. If the problem is real (and I don't yet see it is), we should perhaps discuss its details and invent some new method of disabling compilation with finer granularity. > As for loading, I think there could be a case made to restrict loading > to certain directories managed by "trusted entities", but I think > native-comp-eln-load-path already accomplishes this. Yes, but see below. > If one wanted to disable loading altogether, I'm pretty sure one > could set it to nil and be done (with perhaps the exception that > deferred compilation breaks if there's no path to store binaries > in). I don't think you can set native-comp-eln-load-path to nil. The last entry, the one which points to where the preloaded *.eln files live, must be there, or else Emacs will refuse to start. And at least one other directory should be there as well, because if and when some package advises some primitive, Emacs will need to generate and compile a trampoline .eln file. But yes, if users want to prevent loading from a certain directory, they can remove it from native-comp-eln-load-path, provided that the two necessary entries are still left in the list. > Thus, I think the issue is really only one of inadvertently launching > deferred compilation when all the packages the user *expects* to be > natively compiled are already ensured to be compiled ahead-of-time. This will not happen, so no need to prevent compilation in that case. If a .eln file already exists and is up-to-date, Emacs will not try to compile it again as part of loading the package. If some of the packages aren't natively compiled, against user's expectations, I still see no reason for users to want to disallow JIT compilation, except as a kind of surprise effect due to something they see for the first time. How is JIT compilation different from ahead-of-time compilation? There's nothing really dangerous or harmful in JIT compilation, so all it takes is some getting used to it. Educating your users to get used to it will go a long way towards eliminating the fears, because the dangers aren't real, they are largely imaginary. > I hope this answers some of the questions raised. In short, we believe > that users might want to control not only from where native shared > libraries will be loaded, but also whether to generate them at runtime, > and that (distro) package managers should enable them to compile all > such shared libraries ahead of time – and better yet, in a reproducible > manner, but this hits other bugs I do not want to discuss in detail at > the moment. Thanks for the explanations. I still think the reasons for disabling native compilation are rather weak at best, and the users' requests to allow that based on either bugs that need to be solved or surprise and fears that have no real basis. Moreover, disabling native compilation is a very blunt instrument that cannot be applied better than the existing ones, like no-native-compile (and a few others that we didn't mention; see the defcustom's in comp.el).