[MLton-devel] New release of MLton: call-graphs

[Stephen Weeks]

> I guess my only qualm is that we are using an implementation detail to try
> and capture an implementation independent fact: 
...

It is correct to say that the call graph of a program is
implementation dependent and that with mlton/mlprof we are depending
on implementation details to capture this.  However, I don't entirely
agree with the viewpoint expressed in your mail, which seems to say
that there is some qualitative increase in the level of implementation
dependence when we start to use splitting.

The precise call graph of an SML program is uncomputable.  So our
implementation by necessity makes approximations, which are of course
then implementation dependent.  We use polyvariant splitting,
higher-order flow analysis, inlining, and other optimizations, all of
which affect the precision of the call graph.  Our goal should be to
make the call graph as precise as possible.  All of the aforementioned
optimizations aid in this.  Splitting is just one more technique that
helps us to improve the precision of the call graphs.

> The point being, that if I change the definition of o to
> 
> val (op o) = fn (f, g) => fn x => (print "Composed function called.\n";
>                                    f (g x))
> 
> Then no amount of fiddling with mlprof (or mlton) parameters will recover
> the mlprof graph that is drawn in the previous case, because the
> implementation won't split the o function.

Sure, but there's nothing wrong with this.  It just points to the
necessary imprecision in call graphs that follows from
uncomputability.  Sometimes we'll be precise.  Other times, for no
apparent reason, we won't be.  It's unavoidable.

> I guess all I'm saying is something that should always be said with
> profiling: that the results need to be interpreted carefully.  The problem
> is that when you allow compiler details to leak into the profiling info,
> you make the interpretation that much more careful.

I agree.  It is important to identify up front that the call graphs
are (by necessity) approximations and are implementation dependent.
I'm not so worried about compiler details leaking into the profiling
info, since after all, profiling is about measuring time (or
allocation) which are very compiler dependent :-).

As to -profile-split, I might make a first pass at the new
implementation without it if it makes life easier.  At least we're all
now agreed on what to implement.  Hopefully I can get it done in the
next couple of weeks.

Thanks for all the helpful discussion.


-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel