polyvariant self compile

[Stephen Weeks]

> In the mean while, I tried  to  re-run  both  the  no-polyvariance  compiling
> polyvariant  and  the polyvariant compiling polyvariant on the 1 gig machine,
> and sure enough, this  time  the  latter  was  58%  faster  then  the  former
> (although  something  else must have been going on at the same time since the
> faster version took only a little bit less real time).  I also tried the  no-
> polyvariance compiling with no-polyvariance.  The timings were:
> 
>     no polyvariance compiling with the -no-polyvariance flag:
>             594.85 CPU seconds
> 
>     polyvariant compiling without the -no-polyvariance flag:
>             566.35
> 
> I  don't  see  why  comparing these two numbers makes any sense.

Only in terms of the speed of the compiler development cycle and reaching fixed
point.  It is nice to no that the additional speedup from using a polyvariant
compiler more than makes up for the slowdown due to compiling using
polyvariance.  

> In terms of
> compiler speed for programs people compile (i.e.,  NOT  self-compile)  people
> use polyvariance so you want to run the compiler without the -no-polyvariance
> flag.  In terms of benchmarking what -no-polyvariance  costs  you,  the  most
> sensible comparison is
>     no polyvariance compiling without the -no-polyvariance flag
>     polyvariance compiling without the -no-polyvariance flag
> although I guess you could also compare
>     no polyvariance compiling with the -no-polyvariance flag
>     polyvariance compiling with the -no-polyvariance flag
> although  it  isn't  that important.  Note, even with the stilted comparison,
> running the polyvariant compiler is  still  faster  (although  only  a  small
> amount).

I agree.  Your running times, plus the earlier program sizes (which showed less
blowup due to polyvariance than I recalled) are tempting me to switch to a
use a polyvariantly compiled MLton as the default.

> Does this mean that the ratio SML/NJ compiling MLton to MLton compiling MLton
> is now at the usual values we have come to expect for SML/NJ vs. MLton (i.e.,
> a factor of 2 or better)?

I assume you mean the ratio of running time for G0 compiling G1 vs G1 compiling 
G2?  I.E., I assume you want to compare the same SML program.

Assuming so, I doubt we're there yet, even with the polyvariant speedups.  My
recollection, from the old closure conversion paper, was that we were hardly
getting a speedup on MLton at all, and the polyvariance isn't quite buying us a
factor of 2.  Anyways, I don't have any new numbers, and with all the other
changes (improvements to compiler data structures, X86 backend), who knows.
It's near the top of my list to do some benchmarking before the imminently
forthcoming release, so I'll try to do that as well.