Re: Should "computeLiveTransfers" really take 10 minutes?

On Wed, Feb 15, 2012 at 7:06 PM, Robert J. Simmons <[email protected]> wrote:
> I have a reasonably unsophisticated ML application (a high-level
> interpreter for the C0 programming language, a safe variant of C being
> used in one of our intro courses at CMU). It takes ~15 minutes to
> compile with MLton 20100608 (OSX), which I accepted as a fact of life
> until I compiled with -verbose 3 the other day. I'll attach the full
> output at the bottom of the email, but the hierarchically relevant
> portion of the trace is this: most of the time is spent in two steps:
> "toMachine" right before codegen and "computeLiveTransfers" in
> codegen:
>
>            toMachine finished in 259.36 + 0.66 (0% GC)
>         backend finished in 267.45 + 3.29 (1% GC)
>       pre codegen finished in 337.52 + 46.85 (12% GC)
>            generateTransfers totals 558.65 + 5.92 (1% GC)
>               computeLiveTransfers totals 549.91 + 0.00 (0% GC)
>         outputAssembly finished in 602.52 + 12.96 (2% GC)
>       amd64 code gen finished in 602.53 + 12.96 (2% GC)
>   Compile SML finished in 940.07 + 59.82 (6% GC)
>
> This was unexpected enough that I figured I'd ask if this might be a
> known/unknown performance bug, and if it might have a known
> workaround. Is there a good reason why these stages in particular
> should be tripping us up?

As a workaround, you can try compiling with "-native-live-transfer 0",
which will effectively skip the computeLiveTransfers pass.

I suspect that some aspect of your program is yielding a function with
worst-case liveness calculation behavior.  We ran into this with HOL,
and the SSA2 zone pass is supposed to help:
  http://mlton.org/pipermail/mlton/2004-June/025427.html
  http://mlton.org/pipermail/mlton/2004-June/025437.html

But, looking at your compile log, it seems that the SSA zone pass
isn't doing anything to your program --- all of the program size stats
are the same pre and post the zone pass.  And, the "num blocks in
program" and "num statements in program" seem quite a bit lower than
the problematic sizes with HOL.  Nonetheless, you could try compiling
with "-max-function-size 1000" (which is 10x smaller than the
default); that should do something to your largest functions (since
your "num blocks in program" / "num functions in program" is approx
700).

If the source isn't too secret (I see that the sources aren't yet
available on c0.typesafety.net), then I'd be interested in taking a
look at the "-keep ssa2" and "-keep rssa" intermediate representation
dumps.

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/