[MLton-user] A few questions

Wesley W. Terpstra wesley at terpstra.ca
Fri Dec 7 06:23:04 PST 2007


On Dec 7, 2007, at 2:40 PM, David Hansel wrote:
>  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?

The runtime library is compiled with gcc, but it's doubtful that a  
newer gcc will improve on these (rather short) methods.

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

There is a style guide for readability: http://mlton.org/SyntacticConventions

There is AFAIK no guide for performance. The best tools at your  
disposal are mlprof and reading the output assembly.

Do you know what the bottleneck of your application is?

> - 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.

Correct. Looking over the MinGW web page, it seems that they now have  
some 64 bit support. I would conjecture that the biggest problem to  
overcome now is that none of the people who've ported/worked on MLton  
for windows in the past have a 64 bit version of windows (?). At some  
point I'll try Vista or WinXP 64 and then porting MLton to it would be  
one of the first things I'd do. This hasn't been a priority for me, as  
I use linux for memory intensive applications.

> Has anyone made progress or gained some more insights into this?

To the best of my knowledge, no one has tackled this, as none of the  
developers have needed it.

> - 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?

MLton uses code duplication to eliminate functors and polymorphism. It  
also inlines code fairly aggressively. This results in a larger  
application. You can decrease the inlining, but that will also  
decrease performance.




More information about the MLton-user mailing list