[MLton-user] A few questions

[Matthew Fluet]

On Fri, 7 Dec 2007, David Hansel wrote:
> Using the 20070826 release we were able to successfully
> compile and run our (rather large) code base.

That's great!

> - Although our code runs about 25-30% faster when compiled
>  with MLton compared to SML/NJ,  we were wondering if
>  there are possibilities to improve on that.
>  We are using MinGW to compile on Windows.  However, our
>  MinGW version is quite old (gcc 3.2.3 from 2003-05-04).
>  Given that MLton produces assembly code I would expect
>  that the compiler version does not make a difference
>  concerning performance of the compiled application.  Is
>  that true?

In my experience, most SML programs are not dominated by garbage 
collection or other runtime system components, but if you have a very 
large program that manipulates a lot of data, you might be able to improve 
GC times by moving to a newer gcc.  Though, I've never systematically 
compared gcc versions on the runtime.  I have noticed that recent gcc 
versions have yielded improvements to programs compiled using the C 
codegen.

>  Are there some basic style guidelines that outline good/bad
>  programming styles regarding performance with MLton?

Not really.  Using mlprof is the best way to identify code that might be 
better optimized.

> - One reason why we are considering moving to MLton is to support
>  the AMD64 platform on Windows.  As far as I understand, MLton
>  already can produce 64bit compatible code but the problem is to
>  find a compiler/build system on Windows that produces 64 bit
>  executables.  I found this thread
>  http://mlton.org/pipermail/mlton/2007-July/029907.html
>  which talks about some issues but does not come to a workable
>  conclusion.  Has anyone made progress or gained some more
>  insights into this?

As far as I know, there hasn't been any progress along this front. 
Though, Wesley just posted to the mlton at mlton.org mailing list the 
(positive) results of some efforts in this direction.  So, it doesn't seem 
impossible.

The main difficulty is resources: time, but also machines.

> - We have observed that the executable size for our application
>  when compiled with MLton is about 3x the size of the heap generated
>  by SML/NJ for the same application (60MB vs. 20MB).  Does anybody
>  have an idea what could be the reason for this?  Any suggestions as
>  to how we can track down where the large size comes from?

That is rather large.  The MLton produced executable will include the 
MLton runtime system, whereas the SML/NJ heap would not include the SML/NJ 
runtime system.  But, runtime system is only about 30K.
BTW, is the MLton produced executable stripped?  The native codegen is 
pretty free with assembly labels, so they can add up in an unstripped 
executable.

If you compile with '-verbose 3', you will get a lot of sizing information 
from the intermediate representations.  You can look through the passes 
to see if there is a big increase in program size due to some pass.