From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: Compiler memory consumption Date: Mon, 30 Oct 2017 16:16:13 +0100 Message-ID: <87a808mzsy.fsf@igalia.com> References: <87wp9gwz8m.fsf@gnu.org> <87fug4o8z2.fsf@pobox.com> <87wp54z3p5.fsf@gnu.org> <87po9bjf8v.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1509376648 18172 195.159.176.226 (30 Oct 2017 15:17:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 30 Oct 2017 15:17:28 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) Cc: guile-devel To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Oct 30 16:17:17 2017 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e9BoG-0002kM-AW for guile-devel@m.gmane.org; Mon, 30 Oct 2017 16:17:04 +0100 Original-Received: from localhost ([::1]:41114 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9BoN-00011S-Gm for guile-devel@m.gmane.org; Mon, 30 Oct 2017 11:17:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51126) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9BoF-00011I-3d for guile-devel@gnu.org; Mon, 30 Oct 2017 11:17:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e9BoA-0007Lc-8N for guile-devel@gnu.org; Mon, 30 Oct 2017 11:17:03 -0400 Original-Received: from pb-sasl2.pobox.com ([64.147.108.67]:61223 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e9BoA-00076w-0y; Mon, 30 Oct 2017 11:16:58 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl2.pobox.com (Postfix) with ESMTP id CBEB7A2F3C; Mon, 30 Oct 2017 11:16:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=sasl; bh=B1KrvDNQKghH mvwUluX7m8HWFoo=; b=Um0BuxWPLrdG8jJd3iHJq2phZx5v44fBncSAubgi2mEV Of9M18LpdlCL+YUe8mh6IdHA7WyFbvd2Z7ptTNA/TOXHC9NxoX7Y3jZp/iGOI6wu eSYARsllwv+29qy+71Nbv/ecsRnNjmzY8JiHJCWmabxGw6DlMXuMw09D8F4XUhw= Original-Received: from pb-sasl2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-sasl2.pobox.com (Postfix) with ESMTP id C425AA2F3B; Mon, 30 Oct 2017 11:16:21 -0400 (EDT) Original-Received: from sparrow (unknown [88.160.190.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl2.pobox.com (Postfix) with ESMTPSA id 0AF06A2F3A; Mon, 30 Oct 2017 11:16:20 -0400 (EDT) In-Reply-To: <87po9bjf8v.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Wed, 25 Oct 2017 10:42:40 -0700") X-Pobox-Relay-ID: 490992D0-BD85-11E7-96A9-EA54894C8D7C-02397024!pb-sasl2.pobox.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 64.147.108.67 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19365 Archived-At: On Wed 25 Oct 2017 19:42, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > In short, compiling the top-level thunk is what=E2=80=99s killing us, bec= ause > the space and time complexity is proportional to the number of labels > therein. > > Also, our 16K line python.scm file translates into 428K labels, which > during slot allocation translates into a dozen of 428K-element intmaps > and intsets. So the compilation cost is space per source line of code > is high. > > Andy, what are your thoughts? I think that probably these 428K labels are partitioned into a number of functions. It is true that the biggest one takes the most time. Should we attempt to speed this up, or should we try harder to simplify this graph even at low optimization levels (e.g. "simplify" pass), or should we avoid CSE and periodically split liveness ranges, or should we use a different register allocation strategy on large functions? Or would a transversal solution like a JIT actually be the solution? Or does the stack marking show the same pessimal behavior as the weak table, in that it's a large object behind a mark function? I do not know. I have tried many of the tests that you have done but I don't have a conclusive answer. Andy