No subject

[Stephen Weeks]

> Shouldn't all the uses of mlton just get it using the PATH?  I admit it isn't
> completely clear, but that seems better to me, perhaps adding the  full  path
> to ../bin to PATH first.

This is fine with me as long as there is a way in the makefile to add ../bin to
PATH at the beginning of the makefile and have it exported to all rules.

> As  to  mlton running out of memory, I tried it again and this time it seemed
> to not run out of memory but it was swapping horribly.  (I killed it  when  I
> saw that it was getting less than 25% of real time as CPU time, the rest must
> have been waiting for the disk to page things in  and  out.)   The  size  was
> 250,304K  (which  is  about  right  for  .95  of total).  The amount actually
> resident was 226,304K which is only .86 of total.  We saw this when  the  2.2
> kernels  came  out:  it  seems  that Linux is reserving more memory for other
> processes and the kernel.  Perhaps the .95 should be changed to .85.
> ...
> I changed ../bin/mlton to use a max-heap of 219031k (which is .85  times  the
> MemTotal  line  of  /proc/meminfo)  and  it recompiled mlton.sml fine, taking
> 490.56 CPU seconds and 503.48 real seconds, with only 3.71 seconds of  system
> time,  so  no  swapping.   I claim that this shows that the default should be
> changed to .85.

OK.  Done.

> Oh yes, the resulting mlton.c wasn't quite the same as the one that  came  in
> the  source  rpm.  The date was difference (no surprise) and the call to Main
> was different.  In the rpm it was
>     Main(FALSE, 0, 85316, 3884, 25860, 0xCD21DF2, 4008, initGlobals_0)
> while in the newly created one it was
>     Main(FALSE, 0, 85316, 3884, 25860, 0xAFDAF9D4, 4008, initGlobals_0)
> Note the 6th argument to Main (called mg (yuck)) which is  the  magic,  so  I
> assume that this is ok.

Yep.  This is the uniqifier used by save world to make sure the world and
executable correspond.

> Speaking of which, shouldn't there be runtime arguments for changing the

???

> Perhaps  I  was  confused  because  the  /usr/local/bin/mlton that was in the
> binary RPM you sent out just before the contest had a fixed heap of 350  meg.
> WHY???????  

Actually, I think it was max-heap 350m.  I do this because that's the most I
want MLton to use on my 512m machine, especially when doing self compiles.

> Does  a  fixed  heap  actually  save that much time when running
> MLton?

Not really.  I'd bet 10-20% sometimes.