contification paper

[Matthew Fluet]

> BTW, on the experiments section, I think that what we did in the closure
> conversion paper worked very well.  We ran the numbers on all twenty or so
> benchmarks, but then picked 5-10 representative ones about which we could say
> interesting things.  Other qualities in a good representatives are: large
> # lines, worst performing, best performing.

Yeah, I'm trying to decide which are the right ones to include.  Two
problems with my setup, though.  I couldn't compile mlkit with the
snapshot that I took a few days ago; I ran out of memory with -max-heap
220m.  Which also clearly means I can't get G2 MLton to compile.  I know
those are the two biggest benchmarks; I can get the function counts using
a G0 MLton, but not compile times.

But, here are the one's I'm thinking of:
barnes-hut -- the inlining effect
count-graphs -- dom wins
lexgen -- dom wins
mlkit -- size
mlyacc -- size and no significant variation in performance
hamlet -- size, but dom is worse than call or cont
raytrace -- lots contified by dom, but strangely, none is the best performer
tensor -- huge improvement over none, but call and cont are better than dom
zern -- neat because dom gets it down to a single function; strange,
         because dom lost to call and cont on my benchmarks last night;
         previously, it was doing really well against them (wonder if this
         is an parent vs ancestor thing?)

(Maybe just include self-compile static counts?  What do you use as a
running time for the MLton benchmark?)

I think I'll leave out logic; All analyses have very close running
times.  I'll mention it briefly in context with the complications arising
from the "real" CPS IL, but probably just say that we rarely encounter
uncontifiable functions.

As another note, in thinking about the benchmarks section and talking
briefly about the "real" CPS IL, I instrumented the transformation to
count the number of functions it has to nest because of the mutual
recursion restriction.  Useful statistic: over all benchmarks with the dom
analysis, there are only 38 functions that need to be nested in this way,
out of over 2700 contified functions.  (And the 38 might even be
overcounting, because it will repeatedly count a function if the recursive
calls to sccHeads keep nesting the same functions.)  So, I think we can
reasonably say that it has negligible effect.