🚀 go-pugleaf

Several articles have been posted here which give benchmark results of
the popular C compilers for the ST. I have Lattice version 3.03.01, and am
extremely dissatisfied with its performance on the only benchmark that
really counts: what *I* am trying to do with it. The program predicts
Earth satellite orbit positions and spends 99% of its time number-crunching.

While most benchmarks show Lattice to be somwhat slow in terms
of execution speed, what I am looking for is a factor of twenty improvement.
My wish is not unreasonable, since I have compiled the identical program
on a PC6300+ (80286 @6 MHz) using Microsoft C, and it executed 22 times
faster. Is there any reason why the ST can't outcrunch an AT-clone?

My "benchmark" results are given below for all the machines/compilers
I have tried. If owners of Megamaxx, Mark Williams, and others would
be so kind as to compile the program for me, please send me E-mail and
I will mail you back the source.

The basic problem is: given the orbital parameters of a near-earth 
satellite, the location of the observer, and the day of interest,
compute the position (azimuth, elevation, range, latitude, longitude)
of the satellite for the whole day in two-minute increments. A record
is printed to a file every time the satellite is above the horizon.

Here is a sample of the output:

	noaa-9 Element Set 158

	Doppler calculated for freq = 137.500000 MHz
	Saturday  9 May 87  ----Orbit # 12384-----
 	U.T.C.   Az   El  Doppler  Range  Height  Lat  Long  Phase(360)
	0822:00   26    3    3020    3052     866   61    61   160
	0824:00   34   12    2884    2342     866   54    65   167
	0826:00   50   23    2501    1725     866   47    69   174
	0828:00   83   34    1498    1356     866   40    71   181
	0830:00  127   31    -367    1446     866   34    73   188
	0832:00  153   19   -1974    1933     866   27    75   195
	0834:00  165    8   -2699    2598     865   20    77   202
	0836:00  172    1   -2971    3330     865   13    79   209
	Saturday  9 May 87  ----Orbit # 12385-----
 	U.T.C.   Az   El  Doppler  Range  Height  Lat  Long  Phase(360)
	1002:00    2    0    3051    3373     865   68    80   153

	(etc.)

The source program is public-domain and is written in a generic style
that compiles with very few changes on all compilers I have tried so
far. Here is a summary of the results:

machine		compiler	run time (s)	accuracy
===========	============	========	==========
520ST		Lattice 3.01	480		very good
AT&T 6300+	Microsoft 	22		excellent
VAX 11/785	Unix V cc	4		excellent
Amiga 1000	Manx 		25		poor

Notes -
	My only means of checking the accuracy was to actually pick
	up the VHF beacon of a polar-orbiting satellite as it passed
	overhead. The Lattice results predict the appearance of the
	beacon to within a minute or so and thus my only gripe is
	the abysmally slow speed.

	Curiously, the 6300+ and VAX outputs were *identical*. The
	output is line after line of numbers, yet 'diff' produces
	no output! Obviously, the two compilers are using some kind
	of floating-point standard (IEEE) as well as standard techniques
	of computing trigonometric functions. I therefore am assuming that
	they set the accuracy standard. The Lattice results were 
	slightly different.

	The Amiga/Manx results were obtained using the '-lm' library,
	which the documentation calls the 'Motorola Fast Floating Point
	Package.' Well, it's fast. Unfortunately, the numeric results
	were unusable for this application. They were completely off.
	Manx has other math packages, including IEEE standard. When
	compiled with this package, execution time shot up to 400 seconds,
	but I must've done something wrong, because the output
	was even more ridiculous. If anyone has an Amiga who can try
	out the program and do it right, drop me a line.

	An indication of where at least the VAX was spending all its
	time is given by prof:

 	%Time Seconds Cumsecs  #Calls   msec/call  Name
  	39.9    1.98    1.98    5775      0.343   _sin
  	11.1    0.55    2.53      83      6.6     _write
   	8.4    0.42    2.95    3875      0.108   _sqrt
   	4.4    0.22    3.17    7944      0.027   _cos
   	4.4    0.22    3.38     722      0.30    _asin
   	3.4    0.17    3.55     722      0.23    _Kepler
   	3.4    0.17    3.72       1    167.      _main
   	3.0    0.15    3.87     725      0.21    _exp
   	2.7    0.13    4.00     722      0.18    _GetSubSatPoint
   	2.7    0.13    4.13     722      0.18    _GetBearings
   	2.7    0.13    4.27     722      0.18    _tan
   	2.7    0.13    4.40                      mcount
   	2.0    0.10    4.50                      _frexp
   	2.0    0.10    4.60    4613      0.022   _ldexp
   	1.0    0.05    4.65     725      0.07    _log
   	1.0    0.05    4.70    1444      0.035   _atan
   	0.7    0.03    4.73    1444      0.023   _acos
	(etc.)

	Isn't it weird how sin takes so much longer than cos?
	
Any help on this problem is appreciated. I am leaning towards the conclusion
that the reason the 6300+ performs so well is that IBM PC software is
written to professional standards. What use is the computing power of
the ST if there isn't any means of tapping it?

ihnp4!asr2!jmk	Joe Knapp AT&T Bell Labs, Columbus OH (614)860-3547

"68000" "8.0 MHz"  [ST trees falling in the middle of a forest]