AMXMC-SEL@WSMR-SIMTEL20.ARMY.MIL (Mark Oestmann) (03/06/89)
Not all Ada compilers are created equal. I have been working on a project for reading mark sense sheets from a Sentry 3000 scanner. The results may be of interest to anyone working on real time system with asynchronous input from character devices or limited memory. The code I am writing is to replace a FORTRAN 77 program. The program is completely redesigned IAW structured, object oriented design. The goals of the redesign were flexibility for many applications using the forms, and portability to a VAX 11-785, a UNISYS 5000/80, as well as the original platform of a Data General MV7800. The environment is the ROLM/DGC ADE rev 3.0 under AOS/VS. The problem was speed. The F77 program ran in about 5 cpu seconds to process a test case of 10 sheets. The Ada program required 67 cpu seconds. The question was where was the fault. My first approach to the problem was to test various program elements to determine why the Ada program was such a resource hog. All test but one proved no appreciable difference between the speed of code from the Ada and FORTRAN compilers. The problem was gets from a remote console. The program used 3 milliseconds per character received! The problem does not exist for file i/o with block devices such as disk drives, only with character devices. Using a interface to FORTRAN 77 the runtime was reduced to about 5 cpu seconds. The second approach was to run the code on other machines. We have a VAX 11/785 with DEC Ada compiler, a UNISYS 500/80 with a TeleSoft Ada compiler and Zenith AT compatibles with ALSYS compilers. Due to limitations in DOS, I have not gotten the DOS version operational, but all other systems have been tested and work fine. There are some idiosyncrasies involved in the UNISYS system. Due to the way the OS treats the TTY devices, the same device cannot be opened simultaneously for read and write. This is overcome by opening /dev/ttyx for output and /usr/dev/ttyx for input. Why there are two tty files for each console port, and how they are different is not clear. They are *not* links! Both files work equally well for input and output. The second idiosyncrasy was harder to work around. The input port buffers 4 characters and sends them to the CPU at the same time. This is a problem because the records from the scanner are 48 characters of data and a line terminator. The get_line command never saw the line terminator. The scanner requires acknowledgment of each line received before it send the next line, so deadlock. This problem is not unique to Ada, the cat command behaved the same way on that system. This was solved by adding three nulls to the line terminator. The VMS Ada worked correctly the first time, and worked efficiently. There are very great differences in the speed, size of code, and compile time for the various compilers. The TeleSoft compiler was the slowest compiling and for pure Ada code versions created the largest executable file. The DG compiler was second slowest and produced the second largest code with pure Ada, and with the FORTRAN libraries included, the largest code of all versions. The VMS compiler created the smallest, fastest executable and used the least time in compiling. The results are totaled below. Note that the UNISYS processor is the fastest, the VAX second fastest and the DG the slowest in terms of raw computing power. The compilation amd test were done with little or no other activity on the systems. Overall, DEC's development environment is the easiest to use, gives the best diagnostics, and produces the smallest and fastest code of all the compilers we have used. There are probably other compilers which are just as fast and good, but these are all the compilers we have at SEL. I hope that all developers of Ada compilers will continue working on their compilers with the goal of having the best compiler available on any system. Compiler VAX/VMS TeleSoft ROLM/DGC with F77 ALSYS Compile rate elapsed 2:03 9:33 4:54 5:05 4:50 CPU 54.6 6:03 1:50 1:54 n/a Run time elapsed 60 sec 95 sec 10 min 65 sec n/a CPU 3.98 sec 9.6 sec 67 sec 5 sec n/a Code size 11264 182230 143900 217088 38865 These results indicate that if you are having problems with an Ada program being a resource hog, the problem may not be the Ada code, but the Ada compiler you are using. Gary Dunlap Instructor of General Engineering, School of Engineering and Logistics. -------