[MLton-user] MLton on mswin7 absurdly slow ?

[Matthew Fluet]

On Sun, Feb 6, 2011 at 9:59 PM, John B Thiel <jbthiel at gmail.com> wrote:
> Thanks Anders, Matthew, and Henry.
>
> Anders, your suggestion of a fixed/max heap worked.  The helloworld
> compiles in 30-50 seconds on a 1.66GHz/1GB ram/mswin7 notebook (well
> loaded, 12+ apps open),  given a 100MB heap limit -- either of:
>
> $ mlton @MLton max-heap 0.1g -- hello.sml
> $ mlton @MLton fixed-heap 0.1g -- hello.sml
>
> Compilation failed to complete with a 50MB heap limit as follows:
> $ mlton @MLton max-heap 0.05g -- hello.sml
> Out of memory with max heap size 53,739,520.
>
> The 300MB core/5+ minute time previously reported, was stalling at
> (per -verbose 3) :
>   Compile SML starting
>      pre codegen starting
>         parseAndElaborate starting
>
> It seems there is some runaway allocation with the default options on
> Windows, that unnecessarily overdrives into swap/thrashing.

Interesting.  The default behavior of a MLton compiled program
(including the MLton compiler itself) is to attempt to stay within
one-half of the physical memory of the host machine, unless the
program's execution has live data that exceeds that bound, in which
case it will allow the heap to grow.  Since a 100MB heap worked,
clearly the live data doesn't exceed half of your physical memory.  I
would be curious to see the very first line of:
  mlton @MLton gc-messages -- -verbose 3 hello.sml
On my (amd64-linux) machine, which does have 8GB of physical memory, I get:
  [GC: Found 8,459,915,264 bytes of RAM; using 4,229,959,680 bytes
(50.0% of RAM).]
Perhaps there is something buggy with the way the physical memory is
detected on Win7/MinGW,

> I understand the whole program compilation approach offers some
> intriguing optimization possibilities. Any "real world"
> metrics/anecdotes on % speedups vs other functional languages?

Stephen Weeks' invited talk at ML'06 includes some anecdotes:
  http://mlton.org/References#Weeks06