From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: On elisp running native Date: Thu, 28 Nov 2019 16:06:04 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="262995"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 28 22:51:01 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iaRgg-0016EA-Ki for ged-emacs-devel@m.gmane.org; Thu, 28 Nov 2019 22:50:59 +0100 Original-Received: from localhost ([::1]:53468 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaRgc-0004Ur-Vc for ged-emacs-devel@m.gmane.org; Thu, 28 Nov 2019 16:50:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57283) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iaQza-0004EX-50 for emacs-devel@gnu.org; Thu, 28 Nov 2019 16:06:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iaQzT-0001sV-MV for emacs-devel@gnu.org; Thu, 28 Nov 2019 16:06:21 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10878) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iaQzS-0001Z1-EI for emacs-devel@gnu.org; Thu, 28 Nov 2019 16:06:19 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 24A6F83744; Thu, 28 Nov 2019 16:06:15 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A095F811CF; Thu, 28 Nov 2019 16:06:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1574975172; bh=gPL0YT/sSsXHdwyx1gRFxyi7aRZWjX1yktvsGe0Sv0w=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=gKNE6v32cJR5024Vlfrr4IwT9qZCabhiYvX8tukvSOm/g3tbcbvt9h/cY+FQD9fbI jBJ7y3wl75Ga3K0BUk6Owu2NrtGwXPZkUIPyZUfeiFViXxBMwouo4QCOBu6cNo0JJv yC+8ip2k/DI0EHI6eI3qVTulA4tG7fEVxLfltjFMtLGrj0q3jikCs42EBOu4hRfIJG ZLcUMdk5GtSToOp5qJuYARpr5uMGV1mer47lelfZmIrwouvvnY+2Ny1YV86CxbEwQw q+j2IXBnaJE1HXP9XTJpr8TSqrwlgvZRu/17Vwkqqt5LkITifCaHisq8NBXHleDeij JFyjMd8L9tWUw== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 74F5C1202CE; Thu, 28 Nov 2019 16:06:12 -0500 (EST) In-Reply-To: (Andrea Corallo's message of "Thu, 28 Nov 2019 17:28:00 +0000") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 132.204.25.50 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:242845 Archived-At: >> [ I wasn't able to follow all the explanations at >> http://akrl.sdf.org/gccemacs.html, such as the one around "function >> frames", with which I'm not familiar. Are these like activation >> frames? ] > Yes I think we both mean the same. In this case basically where we store > automatic variables and data related to the single activated function. OK, thanks. I think "activation frame" is the standard term (of which there can be several on the stack at the same time in case of recursion). >> - How did you get there? I see some "we" in the web page, which makes >> it sound like you weren't completely alone. > Sorry for that I'm not much into using 'I'. That's OK, but I see you tried to use it as a clever ploy to dodge the initial question: how did you get there? >> - Have you tried to use the compiler as benchmark (i.e. how much faster >> can Emacs compile (either byte-compile or native-compile)) if the >> compiler code is native-compiled (since it's all using >> lexical-binding already)? > I use the compiler native compiled but because of the previous point I > think is hard to measure the difference. How 'bout measuring the time to byte-compile a given set of files, then: first using the byte-compiled compiler and then using the native-compiled compiler (where "compiler" here means at least cconv.el, byte-opt.el, bytecomp.el, and macroexp.el)? BTW, I think developing a good set of Elisp benchmarks is useful independently from this, so I'd encourage you to submit your benchmarks as a new GNU ELPA package (we could also incorporate it into Emacs itself, but I think we'll want to use it to compare performance between diverse Emacsen, so a separate package makes more sense). Maybe someone from the Gnus side will want to submit more benchmarks (such as one that manipulates "sets/ranges or article numbers"). > Talking about compile time in general I think we are looking at > something like few minutes to compile the whole Emacs at speed 0. The > time goes up to say ~4 hours with 4 cores for the same job at speed 2. [ Compile time varies for me with the normal Emacs from less than 5 minutes to more than an hour depending on the machine on which I compile, so absolute times don't speak to me very much. ] So, IIUC, with enough optimisations enabled, we gets into "a long time" territory? > I think it will be interesting to look into the gcc compilation pipe to > see where we are losing so much time, my guess is that there's one or > few passes that go a little nuts with all the moves we do. I had no > time to look into it but my guess is that once understood the problem we > can probably dime it down. Indeed, I'm surprised that compilation time in gcc would blow up by significantly more than a factor 10 just because of optimisation options, so either we're using optimisations which are really too costly, or there should be something we can do to avoid this blow up without any significant performance loss. Stefan