No subject
Stephen Weeks
MLton@sourcelight.com
Tue, 5 Sep 2000 16:16:16 -0700 (PDT)
> 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.