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: On elisp running native Date: Mon, 09 Mar 2020 18:52:17 +0000 Message-ID: References: <87eeu5txxw.wl-all_but_last@163.com> <8736ah4dlm.wl-all_but_last@163.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="102419"; 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: Zhu Zihao Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 09 19:53:11 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 1jBNWZ-000QTz-5p for ged-emacs-devel@m.gmane-mx.org; Mon, 09 Mar 2020 19:53:11 +0100 Original-Received: from localhost ([::1]:48140 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jBNWY-0004uP-8F for ged-emacs-devel@m.gmane-mx.org; Mon, 09 Mar 2020 14:53:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44745) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jBNVy-00048p-Fp for emacs-devel@gnu.org; Mon, 09 Mar 2020 14:52:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jBNVx-0005GW-6y for emacs-devel@gnu.org; Mon, 09 Mar 2020 14:52:34 -0400 Original-Received: from mx.sdf.org ([205.166.94.20]:56591) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jBNVx-00059G-03 for emacs-devel@gnu.org; Mon, 09 Mar 2020 14:52:33 -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 029IqI9J020152 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 9 Mar 2020 18:52:18 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 029IqHIT013912; Mon, 9 Mar 2020 18:52:17 GMT In-Reply-To: <8736ah4dlm.wl-all_but_last@163.com> (Zhu Zihao's message of "Tue, 10 Mar 2020 01:55:49 +0800") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 205.166.94.20 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:245400 Archived-At: Hi Zhu Zihao, Zhu Zihao writes: > I try to build native-comp branch on Archlinux. It works as expected in the > early stage of bootstrap. But when bootstrapping leim/ja-dic/ja-dic.el with > output: > > ELC+ELN leim/ja-dic/ja-dic.elc > ... > ... > INFO Extracting OKURI-NASI entries...done > > Emacs seems to be frozen and consuming my memories little by little. And > almost 12G RAM was consumed by Emacs when I totally terminate the process. I believe you had just to wait and all was working. leim file are the hardest for GCC to optimize but the most was already compiled. You can just restart from there. > My GCC version is https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commit;h=6957d3e4eef1f4243eb23ff62aea06139ef4415a > both libgccjit and gcc was compiled using this commit. > > Have you exprienced this condition? I've never measured the max memory consumption of the while bootstrap but I usually count like 2GB for each compilation unit when optimizing. Certanly some can be more demanding. Anyway indeed the total memory consumption depends on the parallelism you choose for building. On my main dev machine I've 32GB of ram and I routinary build speed 2 at -j16 without problems. To have a very raw estimation of how long it takes speed 2 you can divide 10h by the number of CPUs you dedicate to the compilation. > Or is there any way to ignore some file in > native-compiling? (like no-byte-compile: t file local variable) Not for now. Should improve a lot when I get to implement the deferred compilation. Andrea -- akrl@sdf.org