[MLton-devel] size of closures

[Matthew Fluet]

> When I first saw the code, I thought we would be OK,
> because known-case would see the dispatch at update, and the two
> control-flow paths that construct a closure and go to the dispatch.
> Unfortunately, known-case doesn't kick in because of the intervening
> V.sub (inp, pos).  It would be nice if known-case were better, but
> it's certainly a hard problem to decide how much intervening code to
> duplicate in order to simplify a case.

Yes.  There is a spot in known-case where I have a constant defined for
the number of statements that can be copied when unrolling a block that
ends in a known case.  (This only applies to a "depth" 0 unrolling, which
prevents code explosion when unrolling a loop with a known argument.)  By
default, though, this constant is 0, so you get the affect above.  I've
never really experimented with other alternatives.  I've got a
half-finished reworking of known case to solve some duplication of
transfers.  (E.g., if you look at the top-level handler for a program that
includes the IO exception, you get two identical big case transfers on all
the exceptions, where it would be better if the recursive printing of the
IO carried exception went through the original case transfer.)  But, it's
still a ways away from prime-time.

That reminds me of one other comment I've been meaning to make.  The
unrolling I mentioned above is inhibited by Profile statements, so a
profiled program and an unprofiled program are affected differently by
known case.  It would be easy enough to change that count of the number of
statements to ignore Profile statements, and that should bring the affect
more in line.  If I understand the handling and use of Profile statements
correctly, copying like this shouldn't increase the final code size by a
significant ammount, because they are just used to statically determine
local source stacks.  (There may be a little code size change, because the
known-case optimization may change the set of local stacks by either
introducing or eliminating some that are in the un-known-case-optimized
program.)

> Of course, this makes it clear that the following code will also have
> the 55M total.
>
> 		   SOME (V.sub (inp, pos),
> 			 if pos + 1 < V.length inp
> 			    then updatePos (is, pos + 1)
> 			 else updateState (is, next))
>
> And I find that code clearest of all.

O.k.  I like that too.



-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel