[MLton] Re: [MLton-user] option ref optimized to a null pointer?
Wesley W. Terpstra
terpstra at dvs1.informatik.tu-darmstadt.de
Sun Nov 25 10:26:33 PST 2007
On Nov 24, 2007, at 10:07 PM, Vesa Karvonen wrote:
> If you run into cases where MLton is unable to optimize the
> representation as you'd expect, you should report it and maybe MLton
> can be improved to handle the case better.
Well, here's an example: (int ref * int ref * int ref) option array.
MLton doesn't flatten the refs into the tuple because the code
elements of the array. So this representation takes 8+8+8+16 bytes on
top of the 4 bytes for the array's pointer.
Contrast this to: (int ref * int ref * int ref) ref option array.
Here MLton is able to figure out that it can flatten the tuple to 16
bytes plus the 4 byte (possibly null pointer) in the array. Less than
half the memory is used.
In fact, this also happens outside of arrays. It seems that you can
generally improve the representation MLton uses for (ref, ref, ref)
tuples / records by adding another ref outside.
It's too bad there's no easy way to get MLton to describe the
representation it is using for a type.
> I think that learning to
> write code in such a way that some compiler will be able to generate
> good code from it is ultimately not very productive (google for the
> story about Levine the Genius Tailor).
In general, I agree. However, if you only intend to use one compiler
and discover that compiler is making a bad choice in the critical
section of your (resource constrained) code, then it pays to hack it.
That's my scenario. By finding the problem (above), I was able to cut
my program's memory usage in half. Not too shabby for adding a single
level of indirection (which is hidden behind a signature anyway).
More information about the MLton