new coalescer on other benchmarks
Stephen Weeks
sweeks@intertrust.com
Wed, 12 May 1999 00:48:25 -0700 (PDT)
> Ok, first things first: the new coalescer seems pretty bad in terms of run
> time:
> old CPU new CPU change
> knuth-bendix 34.77 36.23 -4.2%
> lexgen 65.79 67.62 -2.8%
> mlyacc 41.43 41.54 -0.3%
> ratio-regions 46.54 37.80 23.1%
> simple 44.07 39.06 12.8%
> vliw 41.14 44.78 -8.8%
I'd still consider this a win on the whole. Code size also should
have improved.
> Despite these lousy results, the trampoline counts all improved, except for
> VLIW, which is what I was trying to do:
>
> knuth-bendix 5,970,302 4,693,902
> lexgen 18,588,580 13,094,922
> mlyacc 21,570,876 18,862,276
> ratio-regions 65,436,666 2,494,240
> simple 78,110,715 57,506,745
> vliw 45,479,093 52,652,798
I think there's still quite a bit of room for improvement.
> As to counts, for number of returns, there was no change, except for vliw.
> The old coalescer resulted in code which did 34,952,740 while the new
> coalescer produced code which did 34,952,695. Not much of a change, but I'm
> confused.
...
> Any explanations?
The only thing I can think of is a MLton bug, especially for the
return counts.
I guess we could instrument MLTON_limitCheck (in include/mlton-lib.h)
to output the line number and number of bytes in the check and see the
first place where the number of bytes differs between the two
versions.
As for MLTON_return, I don't see any good way to instrument that. The
"return address" (i.e. uint) in the stackTop is dependent on the
assignment of integers to labels, which is quite dependent on
coalescion.