home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
CP/M
/
CPM_CDROM.iso
/
simtel
/
sigm
/
vols000
/
vol080
/
sample.doc
< prev
next >
Wrap
Text File
|
1985-02-09
|
5KB
|
102 lines
Explanation of SAMPLE Programs
If you like to compare speed records for your
software and/or hardware against other people's, here are
two more "benchmark" programs (or rather, two versions of
the same program), in six different languages (a source
file, in ASCII, for each language -- SAMPLE/*.* -- and the
"COM" files generated by S-BASIC, BDS C, and Pascal/Z, in
case you want to test those on your machine and don't have
the compilers). You can, if you like, use these to prove
that your compiler (Pascal/Z, in this case) is the best,
since each version ran fastest in Pascal/Z. Actually,
though, that wasn't the point of this exercise at all, since
it was something I worked up as a simple demonstration (for
new, prospective computer users) of the differences between
different high-level languages. The main advantage of this
"SAMPLE" program is that it is so simple that it is very
easy to translate it between different languages and do the
same things in each one. As a result, though, it should not
be taken very seriously as a benchmark comparison, since
most of the features of any language will not be tested.
With that disclaimer on record, here are the results
I obtained compiling and running the different versions on
my own system (a North Star Horizon-2, with the standard
4-MHz Z-80; all languages, including North Star BASIC,
running under control of CP/M 2.2). In the table below, "run
times" (all in seconds) are given for "Version 1" (as the
programs were submitted), with an empty loop (all operations
in the loop commented out); and "Version 2", which is
obtained by removing the comment or "REM" indicators inside
the loop in each program. "Compile time" is the time
required to convert the source program (Version 1, in each
case, since the times were almost the same here) to a
running program, with all steps under automatic control of a
".SUB" file (note, however, that if you want to actually do
this with the Pascal/Z program, you will have to change its
name to "SAMPLE.PAS", since, as noted in the "ARTIL/Z.PAS"
program, the Pascal/Z compiler, assembler, and/or linker
will not accept some types of legal CP/M file names, and
this is another example of one that wasn't accepted).
Results of SAMPLE Program Tests
Language Run time (1) Run time (2) Compile time
======== ============ ============ ============
North Star BASIC 35.6 157.0 0
CBASIC-2 16.2 43.8 27.9
S-BASIC 12.5 24.6 55.0
BDS C 0.9 6.4 34.2
Pascal/M 4.1 9.0 40.4
Pascal/Z 0.7 3.6 111.9
You may draw your own conclusions from these data.
Some of my own are:
(1) Don't bother with any version of BASIC; even a
version that compiles to machine code (S-BASIC) is
significantly slower than any of the "good" languages (and
notice, in the program listings, that I had to use some
tricks that weren't in the manuals to get even that good a
performance out of the BASIC's). CBASIC, if written in the
normal way (without using the integer variable tricks shown
in the program), is so much slower than even an interpreter
BASIC (North Star) that it might more properly be referred
to as an "encoder", rather than a compiler -- maybe useful
if you're selling programs that you don't want modified, but
otherwise not much use.
(2) Among the "good" languages, Pascal/Z is slightly
faster, for both versions, than BDS C, even though both
produce machine-code programs; looks like a slight plus for
Pascal/Z, especially for Version 2 of the program.
(3) As expected, Pascal/Z is significantly faster
than Pascal/M, although the advantage is much less for
Version 2 (only a factor of 2.5), where the program actually
has to do something. In my experience with other programs,
especially ones with lots of disk activity, the differences
can be even smaller.
(4) On the other hand, running speed isn't
everything. The third column dramatically demonstrates what
most of you probably know already to be Pascal/Z's worst
"feature" -- waiting for a program to be compiled is like
waiting for Godot. I don't know if there is any easy way for
Ithaca to improve that, but unless you write programs which
run perfectly the first time, the length of the compile-time
cycles can almost make you forget that when that program
FINALLY runs right, it will run a few seconds faster than
the other guy's.
These opinions, of course, are mine alone, not those
of anyone else in the Pascal/Z Users' Group; and while the
speed comparisons may be of interest, I still think that a
better use of these programs is in their demonstration of
how different languages handle the same job. I hope they are
of some use, for either purpose.
Jim Bearden
Cancer Center, University of Hawaii
1236 Lauhala Street
Honolulu, Hawaii 96813
either purpose.
Jim Bearden
Cancer Center, University of HawN##╩▓═*┬Ç═>╬═H<╟7╩▓7═ !╬═$87═┬■N╚■Y┬í╬═%╔:Ä■ô2┬▓:É■?╩▓■K╩ò═┬! ":É■D╩═∩("!δ*%═h.>╥