Nick: 

I am extremely grateful for any effort you can make to get these
benchmarks run in a hurry.     I will be greatly in debt to you.
(As a start, I can send you a copy of my book, when ready!)
Please use SML/NJ version 0.73,
which is available in the same FTP directory.  By the way,
you may want to install 0.73, as it is (probably) much better than 0.66.

Here are the benchmarks.  They are called:

life.sml
lexgen.sml
yacc.sml
leroy.sml
simple.sml
vliw.sml

There are also three files used as input to some of the benchmarks:

ml.grm
ml.lex
ndotprod.s

Finally, there is a shell script to run everything:

runit

After you "csh runit", there should be 12 output files ending
in .out; see if they make sense, and bundle them up and mail them
to me.  If you can get these done during the day and mail them to
me, that's great for two reasons:
   1.  We discover if there are any problems
   2.  I have at least some numbers
Then, if the load was too high, they can be re-run at night.

You may need to edit "runit" to make poly/ml run correctly; I
had to make some guesses.  You may also have to edit the source
files, but I don't so.

The file poly.sml is loaded into the Poly system for SML-NJ compatibility.
The file timeit.sml is loaded into SML-NJ to establish compilation
parameters and to measure compile and run times.

If there aren't at least 40 megs on your SparcStation, you should
probably make the softmax in timeit.sml smaller.

Each of these files contains a structure that matches the signature:
	structure Main : sig val doit : unit -> unit end
so that Main.doit() is measured.

The script starts over with a new sml after running each of these,
since they may put nasty top-level definitions in the environment.

Here are some rough estimates of their compiling and running times (seconds)
on a SparcStation 2 with plenty (>30MB) of memory.  Your mileage may
vary significantly, as the versions of Poly/ML and SML/NJ are now different.

		POLY			SMLNJ

	compile   run		compile  run
life	10      128		 13	27
lexgen	41	 95		 66	20
yacc	abort	--		531	10
leroy	10	116		 30	25
simple	44	461		124	60
VLIW	abort	--		839	45

"abort" means that the front end of the compiler (apparently) takes a long
time and then bombs out with an error message.

What I would like, ideally, is wall-clock time on an unloaded machine.
I think that CPU time is very misleading for Poly/ML; my guess is that
the register-window-overflow traps don't get counted in CPU time(?)
In any case, last time I checked, for SML/NJ user+sys=real,
but for Poly/ML, user+sys=real/2.  Very strange.

The program measures all the times I want (that is, I hope
Poly measures wall-clock time too), so you don't need a stopwatch.

Send mail if you have any questions, or even to let me know
if things appear to be working ok.

					Andrew


