lists,vectors,arrays in SML/NJ and MLton

Matthew Fluet fluet@research.nj.nec.com
Tue, 8 Aug 2000 16:06:41 -0400 (EDT)


> I glanced at what you have and I think the best representation for
> RegisterAllocation.t would be a record with mutable fields 
>   type t = {eax: entry, ebx: entry, ..., esp: entry, 
>             reserved: Register.t list}
> (where entry is modified to be mutable)

Using a record of list refs is working about as well as a vector of lists.
I changed a few of the functions so that all of the accesses of the
registerAllocation.t type go through a small set of functions, so it's
been fairly easy to try out different representations.  Another suprise
was that a record of record of option refs (i.e., give each part a slot)
was pretty bad, although not as bad as array of array.  I suspect part of
this might be tradeoffs between places where I really want to update a
single element quickly and other places where I want to filter or map over
the whole structure.  Creating a list out of the individual pieces is
more costly than simply returning the list that's right there.

I'm curious to see how this works on a self-compile and with a
MLton-compiled version of MLton.  I think it will be a little bit better.
I remember from self-compiles I was doing last week that peak memory usage
was during allocate-registers, but it always fell off when it came close
to using 100%; I suspect that's from the fact that all of these little
vector copies filled the heap, but at a GC all but the current version
could be collected.  This version hopefully will have slightly better
results, since the whole register file won't be copied every time.

> The only thing I can think of is the fact that they have a generational
> collector and so assignments cost them.
> 
> > Would
> > this same behavior appear using the MLton compiled version of MLton? 
> 
> I would be surprised.  In fact, there will be no difference between arrays and
> vectors, and I would bet that mutable arrays are faster than copied lists.  But
> again, I would rather see record types wherever possible.

Well, I'll check it out after getting a self-compile to go through.