[MLton-devel] byte-code compiler experiments

[Stephen Weeks]

To gain some insight into how much having a byte code compiler that
hooks into the MACHINE IL might help us, I ran some self-compile
experiments.  I built the compiler turning off as many passes as
possible, in particulr, with -drop-pass of all of the following:

	simplifyTypes
	polyvariance
	useless
	removeunused2
	simplifyTypes
	contify2
	inline
	localFlatten2
	removeUnused3
	contify3
	introduceLoops
	loopInvariant
	localRef
	flatten
	localFlatten3
	commonArg
	commonSubexp
	commonBlock
	redundantTests
	redundant
	knownCase
	removeUnused4

I'll refer to the version of MLton built with all these -drop-passes
as the "drop" version, and the usual version of MLton as the "normal"
version.  Here is a breakdown of the time it took for various versions
of MLton to build other versions.

			normal 	normal	drop
			making 	making	making
			drop	normal	drop
			------	------	------
	pre codegen	125	200 	 425
	x86 code gen	453	252	1225
	compile SML	578	452	1650
	assemble	 18	 22	  19
	link		  2	  5	   2
	total time	599	480	1675

	size
	---------
drop	7,439,392
normal	8,948,622

Here are some observations:

* Self compiles have slowed down a lot in the last year or so.  We
  used to be around 240s on the same machine.

* By comparing "normal making drop" to "normal making normal" we see
  that there an infinitely fast byte code compiler could speed up
  compilation time from 480s to 125s.  There is still some more room
  for improvement in turning of internal type checking.  For example,
  of the 125s, 27s are for the MACHINE type check.  Factoring in some
  more speedups, and assuming that they more than cancel the time to
  generate byte code, we are talking about two minutes as an estimate
  of total self-compile time for the normal compiler building byte
  code version.

* By comparing "normal making drop" to "drop making drop", we see that
  we pay a roughly 3X-3.5X time hit for turning off most optimizations.
  I did leave a few in, like leaf inlining, or things would have been
  really bad.

* Something weird is happing with the x86 codegen that is causing it
  to be much slower in generating code for the drop case than for the
  normal case.  The drop code is actually slightly smaller, as the
  sizes show.

Overall, two minutes for generating a compiler is a little worse than
I would like for development.  But, I'm not running on a super-fast
machine (1.6GHz) for these days, and combined with our improved front
end that will give *much* faster type error messages than SML/NJ, I
could see that being good enough to live with and an improvement over
our current development environment.  And it would be a huge
improvement on platforms where we don't have a native codegen.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel