fully polyvariant self-compile

Henry Cejtin henry@sourcelight.com
Tue, 15 May 2001 23:47:12 -0500


Encoraged  by  my  test on Rico's 4-gig machines, I just tried to do the same
thing (self-compile MLton without the -no-polyvariance  flag)  on  a  machine
with 1 gig of RAM.  It worked fine.

Here  is  the output of using stock 2001-03-21 MLton to compile mlton with no
-no-polyvariance flag:

	MLton starting
	   Compile SML starting
	      pre codegen starting
		 gcc -DNODEBUG -DMLton_safe=TRUE -DMLton_detectOverflow=TRUE \
		     -I/var/tmp/Z/include -o /tmp/fileoDdYW6 /tmp/fileYpbwA8.c \
		     -L/var/tmp/Z/lib -lmlton -lm -lgmp
		 /tmp/fileoDdYW6 /tmp/filethLesa
	      pre codegen finished in 127.60 + 239.18 (65% GC)
	      x86 code gen starting
	      x86 code gen finished in 390.33 + 140.85 (27% GC)
	   Compile SML finished in 517.93 + 380.03 (42% GC)
	   Compile C starting
	      gcc -S -DNODEBUG -DMLton_safe=TRUE -DMLton_detectOverflow=TRUE \
	          -I/var/tmp/Z/include -o /tmp/fileup7wdZ.s /tmp/fileXtf73F.c
	   Compile C finished in 6.17 + 0.0 (0.0% GC)
	   Assemble starting
	      gcc -c -o /tmp/fileUkyQkO.o /tmp/fileup7wdZ.s
	      ...
	      gcc -c -o /tmp/fileMOorM0.o /tmp/filefwxE7N.0.S
	   Assemble finished in 16.26 + 0.0 (0.0% GC)
	   Link starting
	      gcc -o xxx /tmp/fileUkyQkO.o /tmp/fileMOorM0.o /tmp/fileAgoH1m.o \
		  ...
	          -L/var/tmp/Z/lib -lmlton -lm -lgmp
	   Link finished in 1.29 + 0.0 (0.0% GC)
	MLton finished in 541.67 + 380.06 (41% GC)
	max semispace size(bytes): 224,886,784
	max stack size(bytes): 4,296,704
	GC time(ms): 380,060 (42.3%)
	maxPause(ms): 6,640
	number of GCs: 341
	bytes allocated: 41,940,453,700
	bytes copied: 11,292,451,360
	max bytes live: 188,775,248

	real	15:24.38
	user	913.46
	sys	8.35

and  here  is  the result of using what that produced to compile mlton, again
with no -polyvariance flag:

	MLton starting
	   Compile SML starting
	      pre codegen starting
		 gcc -DNODEBUG -DMLton_safe=TRUE -DMLton_detectOverflow=TRUE \
		     -I/var/tmp/Z/include -o /tmp/file8wC9gl /tmp/fileCq40Nf.c \
		     -L/var/tmp/Z/lib -lmlton -lm -lgmp
		 /tmp/file8wC9gl /tmp/fileegbn5C
	      pre codegen finished in 127.46 + 239.25 (65% GC)
	      x86 code gen starting
	      x86 code gen finished in 392.07 + 140.79 (26% GC)
	   Compile SML finished in 519.53 + 380.04 (42% GC)
	   Compile C starting
	      gcc -S -DNODEBUG -DMLton_safe=TRUE -DMLton_detectOverflow=TRUE \
	          -I/var/tmp/Z/include -o /tmp/fileTzyovB.s /tmp/fileLsLvTy.c
	   Compile C finished in 6.18 + 0.0 (0.0% GC)
	   Assemble starting
	      gcc -c -o /tmp/filekbyk1W.o /tmp/fileTzyovB.s
	      ...
	      gcc -c -o /tmp/fileqEHjds.o /tmp/fileD8a4TX.0.S
	   Assemble finished in 16.21 + 0.0 (0.0% GC)
	   Link starting
	      gcc -o yyy /tmp/filekbyk1W.o /tmp/fileqEHjds.o /tmp/file8vwPWr.o \
		  ...
	          -L/var/tmp/Z/lib -lmlton -lm -lgmp
	   Link finished in 1.28 + 0.0 (0.0% GC)
	MLton finished in 543.23 + 380.06 (41% GC)
	max semispace size(bytes): 224,886,784
	max stack size(bytes): 4,296,704
	GC time(ms): 380,060 (42.3%)
	maxPause(ms): 6,640
	number of GCs: 341
	bytes allocated: 41,940,453,688
	bytes copied: 11,292,451,376
	max bytes live: 188,775,248

	real	15:23.38
	user	915.76
	sys	7.60

So it didn't speed things up any on this machine.  I would guess that this is
due to GC being pretty dominant.

As before, the output of size on the -no-polyvariance version is
       text    data     bss     dec     hex filename
    4013959  675432   29180 4718571  47ffeb lib/mlton
while on the new version it is
       text    data     bss     dec     hex filename
    5688935  842952   30692 6562579  642313 xxx