Re: Should "computeLiveTransfers" really take 10 minutes?

Not really secret at all; the only reason the code's not public is
that the repository includes a bunch of things that are also given as
student assignments; however, if the source would be useful I can
tarball up the repository for you.

Both intermediate representations you mentioned are temporarily hosted
at http://typesafety.net/coin

Thanks!
Rob

On Thu, Feb 16, 2012 at 10:02 PM, Matthew Fluet <[email protected]> wrote:
> 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.



-- 
Robert J. Simmons
simrob.com
gps.simrob.com
[email protected]
[email protected]
Cell: 404-273-6890

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2