From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site burdvax.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!psuvax1!burdvax!eric From: eric@burdvax.UUCP (Eric Marshall) Newsgroups: net.lang.ada Subject: SRI Ada tasking benchmark times by SDC Message-ID: <1872@burdvax.UUCP> Date: Thu, 27-Dec-84 09:13:55 EST Article-I.D.: burdvax.1872 Posted: Thu Dec 27 09:13:55 1984 Date-Received: Thu, 3-Jan-85 04:34:50 EST Organization: System Development Corporation, Paoli PA List-Id: 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