[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compiler memory consumption

From: Andy Wingo
Subject: Re: Compiler memory consumption
Date: Mon, 30 Oct 2017 16:16:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

On Wed 25 Oct 2017 19:42, address@hidden (Ludovic Courtès) writes:

> In short, compiling the top-level thunk is what’s killing us, because
> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]