[net.lang.ada] SRI Ada tasking benchmark times by SDC

eric@burdvax.UUCP (Eric Marshall) (12/27/84)

	SDC RESULTS OF THE SRI ADA* BENCHMARK PROGRAMS

	Here are my results of executing the SRI Ada benchmark programs
that were recently posted in net.sources by Joe Orost. The tests were
compiled with a certified Telesoft Ada compiler executing on a Burrough's
XE-550, which is M68010 based, running System V UNIX. The XE-550 was
configured with 2.5MB of main memory, and 100MB of disk storage. Only a
single user was logged on during program timings.

	The timing of each program was performed as per the original. A
stopwatch was used, and timing started after responding to an initial
prompt from the program, and continued until the program output a
finished message.

	The order100 program had a typographical error in it, and had to
be corrected before compilation. The identifier for the END of the
'ACCEPT GIVE34' statement, on line 278, was incorrect.


COMMENTS ON THE TESTS
	The activation order of tasks by our Telesoft compilers is based
on the lexical order of the task specification. Our Telesoft subset compiler
activates the task that has its specification last, first. The task that
is activated next, is the task with the next to last specification.
Task activation continues until the task with the first specification
is activated. The certifier compiler I used for the benchmark activates
tasks in a reverse order than the subset compiler, the task with the first
specification is activated first, etc. If the Telesoft subset compiler
which was used for the original times, activates tasks in the same order
our subset compiler does, the task that outputs the initial prompt, which
starts the timing, is the last task that is activated, therefore many
things might occur before timing even starts. I rearranged the task
specification order for the chain20 program, so that the task with the
prompt was activated last, instead of first, and incurred a 40 increase
in execution time.

	Here are some ideas that I think could improve the accuracy
of future benchmark programs:

	-  Programs should only run for a finite length of time. Although
	this might not be true of real programs, it makes it easier for
	timing.

	-  There should not be any interaction with the user from the program.

	-  Timing should start with the execution command at the command
	language level. Any initial overhead time should be documented
	with the benchmark times, and people can do with it as they wish.
	The initial overhead on the compiler I used for timing is 20-25
	seconds, and is not included in the times below.

	-  The name of each compilation unit should have the same name as
	the file it resides in. Our subset compiler only allows one
	compilation unit per file, and files output from the compiler are
	named based on the file name. The compiler I used for the benchmark
	allows multiple compilation units per file, and files output are 
	named based on the name of each compilation unit within the file. I
	had been compiling for an hour before I realized that all the
	programs had the same name, and all I was doing was replacing the
	same library files over and over again.



      ORIGINAL TIMES         |          MY TIMES
                             |
program          seconds     |     minutes : seconds
________________________     |     _________________
chain2           3.57        |            0:36
chain5           10.15       |            1:28
chain10          19.66       |            2:55
chain20          38.03       |            5:45
                             |
idle1            29.46       |            5:50
idle5            -           |            5:50
idle10           -           |            5:50
idle20           29.93       |           **1**
                             |
select2          4.38        |            0:47
select2e         4.38        |            0:46
select20         8.42        |            1:37
select20e        8.33        |           **2**
                             |
guard2           4.28        |            0:45
guard2e          4.22        |            0:45
guard20          6.20        |            1:13
guard20e         6.11        |            1:13
guard20t         8.31        |            1:37
guard20et        8.11        |            1:38
                             |
chain2n          29.58       |            5:50
chain2pkt        29.77       |            5:57
chain2ptr        29.98       |            5:57
                             |
passarrys        29.         |            5:58
passarryb        29.         |           **1**
passinout        29.         |           **1**
                             |
moretasks        38.         |           **1**
moretasksl       47.         |           **1**
moreselect       128.        |           26:49 
moreselctr       130.        |           26:49
                             |
order31          28.         |            5:47
order31r         28.         |            5:48
order32         crashes      |            6:08
order100        crashes      |           **3**


	Notes
	**1** - compiler aborts due to an unhandled exception,
                and does not produce a code file

	**2** - source file was not included

	**3** - compiler outputs 'too many jumps',
                and does not produce a code file