SRWMRBD@windy.dsir.govt.nz (ROBERT) (08/11/90)
This is a comparison of 3 C++s for MS DOS.
-----------------------------------------
The compilers are
Glockenspiel C++ version 2.00a running with Microsoft C version 5.1;
Zortech C++ version 2.06;
Turbo C++ version 1.00.
I have a number of programs written in C++. I have attempted to compile
these programs with each of the compilers. I report on problems I
encountered, the length of the resulting code file, the compile time and
the run time. All runs are on an MSDOS machine with an 80386SX and
80387SX.
My programs are largely written in C++ version 1.2 and have been adapted
where required for version 2.0. One program involves multiple
inheritance. Apart form this I have made no attempt to test 2.0
features. I have not tested any of the programs on AT&T C++.
This is not intended to be a complete review - just an initial look at
these three compilers.
I start with some notes on the compilers.
Glockenspiel
------------
This generates C output. I understand it is a modification of the AT&T
translater. It is intended to run with Microsoft C. I am using version
5.1. Glockenspiel intend it to be run with version 6.0. The
documentation says that it "integrates smoothly and seamlessly with the
Microsoft C Professional Development System 6.0". This provides the
development environment. No other development environment is provided.
The syntax manual is on disk with a facility for going to
cross-references. You are expected to use Codeview for debugging.
The compiler uses Rational Systems' Dos extender to take advantage of
memory above 1 megabyte. This is a major advance on earlier versions
which were very prone to run out of memory. Unfortunately this is not
compatible with himem.sys that you need for the extended versions of MS
Windows. This is a himem.sys "feature" and may be fixed one day.
The compiler can handle much longer identifier names than previous
versions. There no longer seems to be any need to define long identifier
names equal to names of around 4 characters.
The compiler comes with what I presume are the AT&T libraries for
complex variables and for input/output. Also included is Commonview, the
interface to Microsoft Windows. I have not tested this. I do not know
whether it will work with Windows 3. The regular Microsoft C library
routines are accessible from C++.
The present version includes only the large compilation model.
The C++ compiler no longer recognises words like FAR or PASCAL except
when defined as being C. I had been developing my own interface to
windows. With the new version of this compiler my code seems to require
considerable upgrading to work with the new version.
While carrying out these tests I installed an 80387. At this point the
preprocessor part of the Glockenspiel compiler refused to run coming up
with an "unexpected interrupt" message. As yet I don't no whether this
is a property of my particular clone or a general fault of Glockenspiel.
I was able to substitute the preprocessor from the previous version of
the Glockenspiel and the tests could continue, except that it runs out
of memory when I am using "make". So with my present setup Glockenspiel
is not suitable for serious development.
Zortech
-------
I have version 2.06 of the compiler. Version 2.1 has just been released.
I am discussing version 2.06 here. I have the 2.1 compiler on order and
will update my review when it arrives. It is a full compiler rather than
a translater to C. Version 2.06 is very much improved over the previous
version I had (1.07e). It can generate the links for Windows code (I
haven't tested this) and comes with the usual range of models. It comes
with an editor, help and a debugger (I haven't tested these seriously),
"make" utility and linker.
The compiler comes with a large run-time library which includes most
(all?) of the routines you expect to come with a C compiler, interface
routines with DOS, and a graphics library. These are all expect to
interface with C. Their is also a C++ library which includes a number of
classes for interfacing with the graphics library. The package does not
include the new AT&T input/output routines.
Turbo
-----
I have the just released version. This is a full compiler rather than a
translater to C. It does not generate code suitable for interfacing with
MS windows. It comes with an editor, help, and a debugger, make, linker
and other utilities. The package also includes an assembler which I
haven't tried yet. It includes the usual range of models.
I am impressed with the environment. This is like an ascii version of MS
Windows allowing access to several windows at a time. This lets you look
at or edit at various pieces of code, help files and error message files
at the same time. It provides a sort of automatic "make" facility which
makes it very easy to set up compilation of a "project" involving
multiple files. There are a few rough edges. For example, when you run a
program from the environment the output vanishes the instant it is
finished.
The compiler comes with a large run-time library which includes most
(all?) of the routines you expect to come with a C compiler, interface
routines with DOS, and a graphics library. Most expect to interface with
C so don't take advantage of the facilities offered by C++. The package
does include at least some of the new AT&T input/output routines. There
are also examples of C++ (eg a spread sheet).
The system includes an overlay manager which I have not tested.
Now reporting on the tests
--------------------------
For each example I carried out the compilation and tests on a 80386SX
MsDOS machine with 4 megabytes of memory and an 80387.
For each example I have scored the success of the compilation of a scale
of 0 to 10. A rough interpretation is as follows:
10: No problems
9: Only very minor problems with no loss of C++ style
7: Minor problems with a little loss of C++ style or difficult to find
5: Problems with some loss of C++ style or difficult to fix
1: Works only with major modification or large loss of C++ style
0: Can't make it work
I have not deducted points when I am not sure what is correct C++. For
example, Turbo does not like nested "for loops" without curly brackets.
For each test I give a brief description of the source file, report of
any problems, award points for the compilation, give the timing data and
length of the .exe file. I give this for both the small and large
models.
In most cases I used the default options that came with the compilers.
Thus Glockenspiel does include some optimisation at the C5.1 compilation
stage. I have not included optimisation with Zortech. Linking does not
include the option for removing excess space and I have not run
"exepack" on them. Spot checks with "exepack" suggest its makes little
difference.
QF1 (430 lines)
---
This is a C program involving much floating point computation and some
logical analysis. For a description and listing on an Algol version of
the program see the 1980 issue of "Applied Statistics". I have carried
out a minimum of translation to make it run under C++. There is quite a
lot of printout.
Zortech and Glockenspiel gave no problems. Turbo apparently interpreted
static global variables and extern variables and the compilation failed
at the link stage. It compiled OK when the static descriptors were
removed.
Compiler Glockenspiel Zortech Turbo
Points out of 10 10 10 7
Small Compile Time (secs) * 13 25
model .exe file length * 33,926 40,676
Run time (secs) * 22 8
Large Compile time (secs) 52 13 25
model .exe file length 40,154 41,828 43,532
Run time (secs) 10 24 8
QF2 (920 lines)
---
This is a translation of QF1 involving much C++ including classes,
virtual functions, arrays operators defined for classes.
Zortech compiled correctly. Here and in every other following example
Glockenspiel reported unresolved externals at the link stage. This is
apparently an incompatibility with MSC 5.1. However the executable file
did run correctly. Turbo reported an error when a "delete" statement was
presented with an expression for a pointer rather than an explicit
pointer. It did compile and run when the pointer expression was evaluted
first and "delete" presented with the resulting pointer. Zortech running
with the optimiser invoked produced incorrect code.
Compiler Glockenspiel Zortech Turbo
Points out of 10 10 10 9
Small Compile Time (secs) * 25 49
model .exe file length * 44,266 91,697
Run time (secs) * 17 12
Large Compile time (secs) 117 26 56
model .exe file length 69,920 58,054 108,376
Run time (secs) 12 20 13
MATRIX (1800 lines)
------
This is a large program for testing a number of matrix manipulation
routines involving a different types of matrices. It makes heavy use of
derived classes, user-defined operators, overloaded operators, and
conversions.
Glockenspiel compiled and ran correctly. Turbo compiled and ran
correctly after I broke one very long expression into 2 parts. Zortech
required some member variables declared as protected to be declared as
public and then ran correctly. My test program counts the number of
times each of the matrix routines is called including the conversion
routines and initialisation routines. Zortech and Glockenspiel had the
same number of calls for each routine; Turbo was slightly different.
Thus Turbo may have slightly different rules for when conversions or
initialisations need to be performed.
Glockenspiel gave quite a number of warning messages relevant to C++
version 2.0 protocols. As yet I don't know enough about version 2.0 to
know whether the compiler was being unnecessarily fussy or whether they
were indicating something I should fix. Turbo also gave a number of
warnings about things like "overload" that are not required in version
2.0.
Compiler Glockenspiel Zortech Turbo
Points out of 10 10 8 10
Large Compile time (secs) 1,164 222 732
model .exe file length 158,862 138,728 309,705
Run time (secs) 3 4 3
RANDOM (1500 lines)
------
A programme for generating random numbers from a large of distributions.
Involves derived classes, overloaded operators.
Turbo ran correctly. Zortech had a recurrence of the problem noted under
matrix. Glockenspiel produced an "internal error" at the C compile
stage. I don't know whether this is a problem with Glockenspiel C++ or
Microsoft C5.1. But it took a lot of work to track down. I had to
simplify two C++ expressions to make it go away.
The files that make up this program include one very long file. This
caused Turbo to do much disk activity which will account for the long
compile time.
Compiler Glockenspiel Zortech Turbo
Points out of 10 8 8 10
Small Compile Time (secs) * 88 363
model .exe file length * 57,898 160,377
Run time (secs) * 105 85
Large Compile time (secs) 488 92 390
model .exe file length 104,412 80,642 183,202
Run time (secs) 78 116 89
INFER (675 lines)
-----
This is an attempt to write a simple inference system in C++ (don't ask
for a copy, it isn't ready yet). It involves derived classes, much use
of heap storage, overloaded operators. Zortech and Turbo ran correctly.
The program originally had variables of type "float". Glockenspiel got
this completely wrong. I think it is an MSC(5.1) problem but illustrates
one of the problems of interfacing with someone else's compiler. When I
replaced "float" with "double" it was OK.
Compiler Glockenspiel Zortech Turbo
Points out of 10 8 10 10
Small Compile Time (secs) * 24 45
model .exe file length * 17,006 78,576
Run time (secs) * 7 10
Large Compile time (secs) 135 25 48
model .exe file length 55,112 23,622 93,737
Run time (secs) 8 8 12
SIM2 (750 lines)
----
This is a simple simulation of the movement of items through a number of
production stages taking account or random processing times. It is the
only example here that makes use of multiple inheritance. Zortech failed
on two counts associated with multiple inheritance, the other two ran
correctly.
Compiler Glockenspiel Zortech Turbo
Points out of 10 10 1 10
Small Compile Time (secs) * 53
model .exe file length * 87,305
Run time (secs) * 41
Large Compile time (secs) 188 58
model .exe file length 65,866 102,642
Run time (secs) 40 44
Summary and conclusions
-----------------------
Here is a summary of the tables. I report only on the large model.
Remember I am using version 2.06 of Zortech. There is a later version. I
would expect the new version to score higher on the points out of 10 but
the other figures to be similar. I am using Glockenspiel with version
5.1 of Microsoft C. Glockenspiel recommends version 6.
Compilation points out of 10
Program Glockenspiel Zortech Turbo
-------------------------------------------------------
QF1 10 10 7
QF2 10 10 9
Matrix 10 8 10
Random 8 8 10
Infer 8 10 10
Sim2 10 1 10
-------------------------------------------------------
Its difficult to say which gives the most reliable compilation. Probably
its Glockenspiel. But Glockenspiel almost scored straight zeroes owing
to its difficulties with the 80387 on my machine. I expect Zortech has
sorted out at least some of the problems found here in its current
version. Turbo's high score in this initial release must be a warning to
the others.
Compile times (seconds)
Program Glockenspiel Zortech Turbo
-------------------------------------------------------
QF1 52 13 25
QF2 117 26 56
Matrix 1,164 222 732
Random 488 92 390
Infer 135 25 48
Sim2 188 58
-------------------------------------------------------
Zortech is a clear winner here. Turbo takes about twice as long and
Glockenspiel twice as long again.
exe file length (1000 bytes)
Program Glockenspiel Zortech Turbo
-------------------------------------------------------
QF1 40 42 44
QF2 70 58 108
Matrix 159 139 310
Random 104 81 183
Infer 55 24 94
Sim2 66 103
-------------------------------------------------------
Zortech is the winner here with Glockenspiel a close second. Less close
if you can use the small model with Zortech. I suspect the difference
(about 20K) arises from a longer run time library in Glockenspiel,
possibly due to the AT&T i/o routines. I think Turbo's very long code
files are a significant disadvantage with Turbo.
Run time (secs)
Program Glockenspiel Zortech Turbo
-------------------------------------------------------
QF1 10 24 8
QF2 12 20 13
Matrix 3 4 3
Random 78 116 89
Infer 8 8 12
Sim2 40 44
-------------------------------------------------------
Glockenspiel wins here with Turbo a close second. But my examples
involve a lot of numerical computations. Maybe Zortech's use of the
80387 is not so efficient. In the one example that does not involve much
numerical work Zortech is up with the rest.cline@cheetah.ece.clarkson.edu (Marshall Cline) (08/14/90)
In article <18359@windy.dsir.govt.nz> SRWMRBD@windy.dsir.govt.nz (ROBERT) did a very nice job comparing/contrasting 3 C++ compilers for MSDOG (oops -- slip of the fingers): Glock 2.00a, Zortech 2.06, TC++ 1.00. This kind of information will become more and more important as we have more and more and more good C++ compilers to choose from. [[As an aside, isn't it fun working with a language where software houses are racing to get quality compilers out??!!]] Robert, I have a question. You said: >The [Glockenspiel] compiler uses Rational Systems' Dos extender to take advantage of >memory above 1 megabyte. This is a major advance on earlier versions Did you have any use of above-640K ram for TC++? I don't know if it matters for Zortech, but TC++ speeds up *immensly* when you give it a RAM-disk or Extended/Expanded memory to work with. The compiler itself is 800+K bytes, which includes its overlays etc. If you didn't give TC++ a fast-swap device, you might want to re-do the compile-time tests and see how they fare. Same with Zortech (if indeed Zortech can take advantage of ram-disks etc). Marshall Cline -- ============================================================================== Marshall Cline / Asst.Prof / ECE Dept / Clarkson Univ / Potsdam, NY 13676 cline@sun.soe.clarkson.edu / Bitnet:BH0W@CLUTX / uunet!clutx.clarkson.edu!bh0w Voice: 315-268-3868 / Secretary: 315-268-6511 / FAX: 315-268-7600 Career search in progress; ECE faculty; research oriented; will send vita. PS: If your company is interested in on-site C++/OOD training, drop me a line! ==============================================================================
bright@Data-IO.COM (Walter Bright) (08/14/90)
In article <CLINE.90Aug13125908@cheetah.ece.clarkson.edu> cline@sun.soe.clarkson.edu (Marshall Cline) writes:
<If you didn't give TC++ a fast-swap device, you might want to re-do the
<compile-time tests and see how they fare. Same with Zortech (if indeed
<Zortech can take advantage of ram-disks etc).
The Zortech compiler passes do not overlay code or data, since that is
not necessary with a DOS extender, thus there is no need for a swap
device. However, the temporary files are written out to the TMP device,
so it is definitely worthwhile to set the environment variable TMP
to be your ram drive. I also load at boot time the compiler passes up
on the TMP drive.