[MLton-devel] icfp

[Suresh Jagannathan]

On Monday 24 February 2003 10:34 pm, Stephen Weeks wrote:
> > These languages use types in their ILs to ensure the correctness of
> > the compiler,
>
> This is too strong.

Perhaps "use types" should be rephrased to "are motivated to use types"

>
> > In these implementations, the ILs themselves are expressed using a
> > rich type system, often tailored to exploit specific characteristics
> > of the source language.  This approach suffers from two drawbacks.
>
> I like this point -- Flint, TIL(T), and CIL all suffer from this to my
> mind.
>
> > In this paper, we present a systematic evaluation of the compilation
> > strategy used in \mlton, an optimizing compiler for Standard ML.
> > \mlton\ transforms SML programs early in the compilation process to
> > a first-order simply-typed IL.
>
> This bit makes me think that the right thing for us to do is to write
> a mini-opus, kind of like the original TIL paper.  We could focus on
> the benefits of whole-program compilation, first-order simply-typed
> SSA as our main IL, and performance of generated code.

I'm wary of simply presenting a mini-opus.  I think enough people are familar
with MLton by this point to question a publication that summarizes its
structure and presents performance measurements that been more or less
available via various releases for some time now.

>
> > We have developed an allocation and time-based profiling tool for
> > \mlton, and apply it to a range of benchmarks, including the
> > compiler itself, to help verify the feasibility of this approach.
> > Profiling data indicates that \mlton's compilation strategy is
> > effective, yielding code efficient in both runtime and allocation
> > costs.
>
> I, like Henry, am confused.  I can see using the profiler to analyze
> the compile time costs (time and allocation) of manipulating types.  I
> don't see how it helps us understand the wonderfully efficient code
> that MLton generates.  As I said before, I could see some careful
> analysis of running a profiled MLton supporting conclusions like "only
> 10% of the time (or allocation) is spent manipulating types".  That
> would fit nicely into a mini-opus as well.

Right -- my main goal was to focus on the compiler.  So, it's probably
true we can elide detailed discussion of other benchmarks other than
to point out that simplicity in IL design does not lead to inefficiency in
execution.  I now see the paper as having the following parts:

1. overview and rationale for simply-typed ILs and the need for 
whole-program compilation.
2. description of the profiler
3. profiling a self-compile to quantify the costs of type manipulation

There might be a smaller section that describes some benchmarks.

While I think you're right that the profiler could be presented as a separate
paper, I think giving an overview in this paper would be appropriate.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel