heap allocation for MLton object instatiation test?

[Stephen Weeks]

> I hope I'm not bugging you, 

Not at all.  I am very appreciative of your page and the amount of work it takes
to maintain.  We are always happy to help out to keep MLton's benchmarks up to
date 

> but I was wondering if this program 
> 
>  http://www.bagley.org/~doug/shootout/bench/objinst/objinst.mlton
> 
> could be modified to do a create object/destroy object on the heap for
> every iteration of the instantiation loop?
> 
> I don't know for sure, but I think that it isn't doing that right now.

I looked at the intermediate code, and you are right, it is not.  The reason is
that MLton's optimizer is smart enough to notice that in the following line, the
allocated toggle is not used.

      val _ = for (0, n - 1, fn _ => Toggle.new true)

So, it completely optimizes the create/destroy away, and has simply a loop from
0 to n - 1.

One can (partially) defeat MLton's current optimizer by replacing the above line
with the following three.

      val r = ref (Toggle.new false)
      val _ = for (0, n - 1, fn _ => r := Toggle.new true)
      val _ = Toggle.activate (!r)

Now, MLton will allocate the toggle on each step and store it into r, just so
that it can activate it later.  As one of the MLton developers, I am somewhat
embarassed that MLton didn't also notice that the Toggle.activate is also
useless and remove it (and then all the allocation).  But at least for now, it
does not.

One other thing that I should mention that skews (improves) the performance of
this benchmark for MLton is that it notices that only the state field of the
toggle is important, and optimizes away the value and activate fields.  So, it
is only allocating an object with a single field (in fact, it should remove that
allocation as well, but doesn't for now).

> I'm not even sure if that makes sense in SML, but I was hoping you
> could enlighten me.

It's really tough to get microbenchmarks in SML (even more so with MLton),
especially when trying to talk about allocation, since the language
specification is at a higher level, and gives great freedom for optimizers.