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: Mon, 06 Jun 2022 02:12:30 -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="4680"; 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 Mon Jun 06 08:20:49 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 1ny66b-0000zB-Ka for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Jun 2022 08:20:49 +0200 Original-Received: from localhost ([::1]:56446 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ny66Z-0003Ha-UK for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Jun 2022 02:20:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39756) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ny5yg-0008S6-Ni for emacs-devel@gnu.org; Mon, 06 Jun 2022 02:12:40 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16444) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ny5yd-0000Dm-T0 for emacs-devel@gnu.org; Mon, 06 Jun 2022 02:12:37 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 77238440910; Mon, 6 Jun 2022 02:12:33 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DFF39440811; Mon, 6 Jun 2022 02:12:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1654495951; bh=ucTmW69zYn2zRpQ40mwi6zfc+WYUXvaJy7QJ7rb3yBA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=RGyo15BfIkBpCmHBc7z/+nqdQJ0M3D74uT3bqXcdBEZWVWD3fa0tdyUpbR1KvfGVT O4CnvLDJ/ibpfdAwM092JkLUyirhf3q1oCHwp9dDfcr84XjAjb+kLaB8SsEO8RkSif D3E01/zwuxXtvhf3xzD9DE4YR19zTrXLZZQUzrMNqbsbL/hURcbnmh9W0d/4LnVA4z vyX3VFJD22Xrc7qDLZ1xpobvGRae8TWwVmgU3ryhIY1m/HlfWEZblT1EuNsocqirO9 r57vd3pwgF4IuGfTT/b4UJA+iFEPkv1kn4knTGm9k40uNpf8lf4W8W26IUNQfafT9p TJYOlkzaWJ0JQ== Original-Received: from pastel (unknown [45.72.221.51]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id ADABB120317; Mon, 6 Jun 2022 02:12:31 -0400 (EDT) In-Reply-To: (Lynn Winebarger's message of "Mon, 6 Jun 2022 00:12:29 -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:290769 Archived-At: > Not sure if these general statistics are of much use, but of 4324 source > files successfully compiled (1557 from the lisp directory), with a total > size of 318MB, including 13 trampolines, > The smallest 450 are 17632 bytes or less, with the trampolines at 16744 > bytes, total of 7.4M > The smallest 1000 are under 25700 bytes, totaling 20M > The smallest 2000 are under 38592 bytes, totaling 48M > The smallest 3000 are under 62832 bytes, totaling 95M > The smallest 4000 are under 188440 bytes, totaling 194M > There are only 58 over 500k in size, and only 13 over 1M (max is 3.1M) > Those last 58 total about 52M in size. The way I read this, the small files don't dominate, so bundling them may still be a good idea but it's probably not going to make a big difference. > I am curious as to why the system doesn't just produce trampolines for all > the system calls AOT in a single module. Trampolines are needed for any native-compiled function which gets redefined. We could try to build them eagerly when the native-compiled function is compiled, and there could be various other ways to handle this. There's room for improvement here, but the current system works well enough for a first version. > True, but it does lead to a little more disappointment when that 2.5-5x > speedup is dominated by the load-path length while starting up. I don't know where you got that 2.5-5x expectation, but native compilation will often result in "no speed up at all". > That would explain the behavior I've seen. If that's the case, shouldn't > batch-native-compile produce the byte-compiled file if it doesn't exist? Sounds about right, tho maybe there's a good reason for the current behavior, I don't know. Maybe you should `M-x report-emacs-bug`. > Sorry, no. I meant I'm curious if having them in the user's cache versus > the system ELN cache would make any difference in start-up time, ignoring > the initial async native compilation. In particular whether the checksum > calculation is bypassed in one case but not the other (by keeping a > permanent mapping from the system load-path to the system cache, say). No, I don't think it should make any difference in this respect. > I'm guessing the native compiled code is making the GC's performance a more > noticeable chunk of overhead. Indeed, the GC is the same and the native compiler does not make many efforts to reduce memory allocations, so fraction of time spent in GC tends to increase. > I'd really love to see something like Chromium's concurrent gc > integrated into Emacs. Our GC is in serious need of improvement, yes. Bolting some existing GC onto Emacs won't be easy, tho. > If I do any rigorous experiments to see if there's anything resembling a > virtuous cycle in larger compilation units + higher intraprocedural > optimizations, I'll report back. Looking forward to it, thanks, I'd be interested as well in seeing a `profile-report` output covering your minute-long startup. Stefan