[MLton-devel] cvs commit: C codegen cleanup

[Stephen Weeks]

> I notice that you have defined:
...
> Has this had a noticable impact on runtime performance?

Yes, although not as much as I would have guessed.  I just started
some benchmarks:

MLton0 -- mlton-20030512 -native false -cc-opt -O1
MLton1 -- mlton-20030512 -native false -cc-opt -O2
MLton2 -- mlton-20030513 -native false -cc-opt -O1
MLton3 -- mlton-20030513 -native false -cc-opt -O2
run time ratio
benchmark    MLton1 MLton2 MLton3
barnes-hut     0.88   1.06   0.98
boyer          0.91   1.11   0.98
checksum       0.86   1.02   0.84
count-graphs   0.55   1.05   0.77
DLXSimulator   0.91   1.05   1.02
size
benchmark     MLton0  MLton1  MLton2  MLton3
barnes-hut   141,517 138,509 144,612 140,388
boyer        145,673 143,241 184,441 178,841
checksum      56,217  56,217  56,009  55,625
count-graphs  77,209  75,513  80,233  77,865
DLXSimulator 130,818 124,578 145,234 137,522
compile time
benchmark    MLton0 MLton1 MLton2 MLton3
barnes-hut     4.79   5.78   5.83   6.95
boyer         23.20  26.90  63.30  68.60
checksum       0.87   0.90   0.75   0.85
count-graphs   2.95   3.41   3.33   4.09
DLXSimulator   8.20   9.72  13.67  15.44
run time
benchmark    MLton0 MLton1 MLton2 MLton3
barnes-hut    36.66  32.41  38.89  35.96
boyer         45.43  41.50  50.26  44.65
checksum      73.47  63.38  74.92  61.57
count-graphs  58.65  32.44  61.70  45.33
DLXSimulator  82.15  75.04  86.30  83.48

A 5-10% hit with -O1 and even more with -O2 is more than its worth.
And I'm sure we would see a bigger hit with the native codegen.

> I ask, because without a number of hacks (which would essentially expose
> the Machine.Operand.Runtime variant), the native codegen won't be able to
> determine which operands correspond to the stackTop and which correspond
> to the frontier.  Currently, the x86-codegen works hard to keep those
> values in registers. 

Yeah, frontier and stackTop are special enough to single out.  How
about the following intermediate position.

Eliminate Machine.Operand.Runtime, but add Machine.Operand.StackTop
and Machine.Operand.Frontier.  That will let the codegen know about
those special two, but eliminate the cruft that deals will all the
other ones.  It still requires the native codegen to support offsets
from gcState (but naively is fine).


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel