From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: native compilation units Date: Fri, 03 Jun 2022 14:15:05 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36316"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Andrea Corallo , emacs-devel@gnu.org To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 03 20:16:28 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 1nxBqW-0009F1-20 for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Jun 2022 20:16:28 +0200 Original-Received: from localhost ([::1]:40182 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nxBqU-000178-VQ for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Jun 2022 14:16:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43608) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxBpU-0000GH-5J for emacs-devel@gnu.org; Fri, 03 Jun 2022 14:15:27 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36405) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nxBpO-0002uQ-UW for emacs-devel@gnu.org; Fri, 03 Jun 2022 14:15:22 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 463C41006F8; Fri, 3 Jun 2022 14:15:13 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5BC91100171; Fri, 3 Jun 2022 14:15:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1654280107; bh=qZWX+wrA1AOc9wCngD3+nEwNi7WAOhHAECmv0g3uhPA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=PGaRbgI1Dn/wVRwWaj4o0rqHuBychpBSRjW/3I+OXEhzDpqI/xvZ9tj92N2lLb0Ex DOMSahA37pspZOkA9d453c1EFlI36/64+76OObyAmC0nTMqkJjCA0yaEyFA2sAEf2p eSxPC7mkp/RfZpfDIpZzmB2frFlyOV3BziI7wlvh/Qbn+7QhceekC1LbWMr03KwYvI H4JK3sELYCVPYrhS9jRyGVim0q4FSq/nTjtUQ27F4rMyLVIZpW/zJOCVQ1UiiF6cEk Up9h4HUKxP78uh3ABOl/h8ZJ7xv/ruhMuvBO6KshwhfqHJzNZm2L3pgcjs13+XalEG 4h6L76sd3D7RQ== Original-Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EA5E9120480; Fri, 3 Jun 2022 14:15:06 -0400 (EDT) In-Reply-To: (Lynn Winebarger's message of "Fri, 3 Jun 2022 10:17:25 -0400") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham 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:290634 Archived-At: > There was a thread in January starting at > https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01005.html that > gets at one scenario. At least in pre-10 versions in my experience, > Windows has not dealt well with large numbers of files in a single > directory, at least if it's on a network drive. Hmm... I count a bit over 6K ELisp files in Emacs + (Non)GNU ELPA, so the ELN cache should presumably not go much past 10K files. Performance issues with read access to directories containing less than 10K files seems like something that was solved last century, so I wouldn't worry very much about it. [ But that doesn't mean we shouldn't try to compile several ELisp files into a single ELN file, especially since the size of ELN files seems to be proportionally larger for small ELisp files than for large ones. ] > Aside from explicit interprocedural optimization, is it possible libgccjit > would lay out the code in a more optimal way in terms of memory locality? Could be, but I doubt it because I don't think GCC gets enough info to make such a decision. For lazily-compiled ELN files I could imagine collecting some amount of profiling info to generate better code, but our code generation is definitely not that sophisticated. > If the only concern for semantic safety with -O3 is the redefinability of > all symbols, that's already the case for emacs lisp primitives implemented > in C. Not really: - Most ELisp primitives implemented in C can be redefined just fine. The problem is about *calls* to those primitives, where the redefinition may fail to apply to those calls that are made from C. - While the problem is similar the scope is very different. > It should be similar to putting the code into a let block with all > defined functions bound in the block, then setting the global > definitions to the locally defined versions, except for any variations > in forms with semantics that depend on whether they appear at > top-level or in a lexical scope. IIUC the current native-compiler will actually leave those locally-defined functions in their byte-code form :-( IOW, there are lower-hanging fruits to pick first. > It might be interesting to extend the language with a form that > makes the unsafe optimizations safe with respect to the compilation unit. Yes, in the context of Scheme I think this is called "sealing". Stefan