From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: Native compilation: the bird-eye view Date: Sat, 16 May 2020 17:03:13 +0000 Message-ID: References: <83o8qocd32.fsf@gnu.org> <83ftbzdewp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="52266"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat May 16 19:04:21 2020 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 1ja0EW-000DTl-Rk for ged-emacs-devel@m.gmane-mx.org; Sat, 16 May 2020 19:04:20 +0200 Original-Received: from localhost ([::1]:46244 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ja0EV-000196-To for ged-emacs-devel@m.gmane-mx.org; Sat, 16 May 2020 13:04:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47052) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ja0DU-0000ey-Hw for emacs-devel@gnu.org; Sat, 16 May 2020 13:03:16 -0400 Original-Received: from mx.sdf.org ([205.166.94.20]:55409) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ja0DT-00063W-GJ; Sat, 16 May 2020 13:03:16 -0400 Original-Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04GH3DXV029319 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 16 May 2020 17:03:13 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04GH3DAH011747; Sat, 16 May 2020 17:03:13 GMT In-Reply-To: <83ftbzdewp.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 16 May 2020 19:26:46 +0300") Received-SPF: pass client-ip=205.166.94.20; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/16 11:24:11 X-ACL-Warn: Detected OS = ??? 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN 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:250505 Archived-At: Eli Zaretskii writes: >> From: Andrea Corallo >> Date: Sat, 16 May 2020 12:58:11 +0000 >> Cc: emacs-devel@gnu.org >> >> > If so, they will have >> > to be generated on the end-user machines, or perhaps by whoever >> > prepares the Emacs binary distributions -- assuming that the binary >> > distributions are sufficiently compatible to allow that, >> > notwithstanding the differences between the system where the *.eln >> > files were generated and the system where they will be installed and >> > used. (I don't know what is the granularity of the binary distros wrt >> > machine architecture and OS versions -- will that allow to be sure the >> > *.eln files are compatible with the target system?) >> >> Given .eln are just shareds with (almost) no dependecies [1] their >> degree of compatibility should be higher then the Emacs binary itself. > > Well, the "almost" part means we aren't actually sure about this. > E.g., what about the dependencies related to the GCC version used to > build libgccjit and compile the .eln files? For 'almost' I meant what I listed in [1]. AFAIK The GCC version used to build libgccjit and compile the eln as no dependency implication once the eln has been produced. >> > The next question is whether we want the *.eln files to exist up front >> > for all the Lisp files on the end-user system, or we want them to be >> > generated in JIT-like manner, whenever the corresponding Lisp library >> > is loaded on demand? The answer to this question might then influence >> > the place where the *.eln files are kept -- the JIT alternative would >> > suggest to have some kind of cache directory where we put the compiled >> > files, similar to what Guile does. >> >> I suspect that for the average user the best is to have the distribution >> do all the compilation upfront for him and have deferred compilation >> handling only additional libraries and packages. > > And for the "non-average" user, who builds Emacs from sources? AFAIU, > native compilation of all Lisp files takes many hours even on fast > machines -- won't this be an annoyance if we don't come up with a JIT > mechanism? I'm not sure but I guess than the 'JIT mechanism' is already in place and called 'deferred-compilation'. Isn't it? Andrea -- akrl@sdf.org