[MLton-user] Questions on MLton

[Stephen Weeks]

> Thanks for the near-instantaneous reply!

Oh, that was just a bot that I leave running overnight while I'm
asleep.  Pretty good, huh.

> What I am doing is hacking linked lists destructively -- so type analysis
> won't help, right? Doing a SET-CDR! in SML smashes a list into memory, not a
> bool or char or something where you could sleaze the write barrier. Alas.

True.  But the write barrier at least won't cost you in other places
where it shouldn't.

BTW, you are probably gonna pay a lot for destructive lists in SML
with MLton, since the ref cell costs an extra two words.  We don't
have an optimization to flatten ref cells into their containing
structures, although we would love to see one.

> OK, let me unburden myself with the whole plan. I am timing a slew (~ 10-15)
> of sorting algorithms.
...
> So I end up with a matrix:
>   - the rows are the sort algos
>   - the columns are the various kinds of lists.
> 
> Hence, I split out timing info for each elt of the matrix. Note that it's
> interleaved like this: generate a list, then sort it with each algo. Then
> make up another list, rinse, repeat.

Given this setup and the fact that you want total time of the toplevel
sort function only, the Timer structure is the way to go (you could
also use Posix.ProcEnv.times).  The profiler is more for finding
hotspots when you don't know where to look.

> Now, I see in the doc that one can allocate different profiler structures
> and somehow do some sort of thing or another with these things. 

Think of profiling data as a map from source functions to clock ticks.
If you just use the usual profiling, then you get a single map for the
entire run of the program, and every timer interrupt increments the
counter corresponding to the current function.  When you use
MLton.Profile.Data.t, you get lots of maps from source functions to
clock ticks and can decide, via MLton.Profile.withData, which one
should be used by the timer interrupt handler at any given time.

Anyways, I don't think MLton.Profile is relevant for what you want.

> BTW, one of the functions that typically runs inside the top call to the sort
> is list merge... which can push *thousands* of stack frames. Is this going
> to make the stack profiler unhappy?

Yeah, I could believe list merge will make -profile-stack true
unhappy.

> But, on the one hand, Mlton doesn't produce asm for Sparc,

True.  But the C codegen may not be as bad as you would think.  We've
put some work into generating C code so that gcc will optimize well.
Interestingly enough, our experiments on X86 have shown that the C
codegen and the native codegen aren't that far apart.  The C codegen
produces executables that almost always run within a factor of 2 of
the native one, and often within 1.5.