(none)
Ross Taylor
experiences with Fortran compilers on 386 machines. I received a
few replies that I will share with you as I notice that there
have been some more postings lately regarding Fortran on these
type of machines. (The entire message is about 15 screens).
First, a list of 386 Fortran compilers that I know about:
1 Lahey F77L-EM/32
2 LPI
3 NDP Fortran from Microway
4 FTN77/386 distributed by OTG
5 SVS Fortran-386
6 Watcom F77/386
Please excuse any omissions, these are the ones I have read
about.
Now for a list of some references to published reviews on 386 Fortrans:
1. Fortran on the 386
M. Stephen Baker
Programmers J. July/August 90
Gives a few benchmarks for all of the above but for a beta
version of Watcom's compiler.
No definite recommendations.
2. Fortran Roundup
Scott Robert Ladd
Computer Language, November 1988
Compares compilers 1-4 from above list.
FTN77 from OTG got good marks.
Note, however, this is 2 years old.
3. Fast Fortrans for Number Crunching
A.G.W. Cameron
Personal Workstation, July 1989
Looks at 1, 2, 3 and 5.
Liked 5 and 1 most I think
4. Fortran Revisited
A.G.W. Cameron
Personal Workstation, August 1990
Looks at OTG FTN77 and updated NDP compilers
No definite recommendations, just a summary of features.
5. Fortran Fever
Jack Crenshaw
Computer Language, April 90
More about this review later.
There was a reply to it in November 90 Comp Lang from Lahey and
Salford (they make FTN77) presidents. More on this later as
well.
Now for the comments I received. I will use ++++++ to separate
remarks from different respondents.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Ian Jamie (ja...@rsc0.anu.oz.au) sent the following info from
Crenshaw's review (LONG)
I scanned the the text using OCR, then did a bit of editing to fix
up poorly recognised characters. Any typos and manglings are a result of
this and my poor proof-reading, not the fault of the original document.
I went for MS F77 V5.0 because it was available as and upgrade to V4.?
which we already had in the department, and which I am reasonable familiar
with.
TABLE l.
Compiler features
Microsoft Lahey Lahey OTG Microway SVS
F77 F77L F77LEM/32 FTN77 NDP F77
5.0 4.01 2.01 1.67 2.0.6 2.8
Utilities
Editor Yes Yes No No No No
Linker Yes Yes Yes Yes (1) (1)
Librarian (2) Yes Yes (3) (1) (1)
make Yes Yes No No (1) No
Debugger Yes Yes No Yes No Yes
Profiler No Yes No Yes No No
Support
80286 instructions Yes Yes No No . No No
80386 instructions No Yes Yes Yes Yes Yes
386 protected mode No No Yes Yes Yes Yes
DOS extender No No Yes Yes (1) (1)
Virtual memory No No No Yes (1) (1)
Coprocessor support
Emulation mode Yes Yes No Yes No No
80287 Yes Yes Yes Yes No Yes
80387 Yes Yes Yes Yes Yes Yes
Weitek No Yes Yes (5) Yes Yes
Language extensions
DO-WHILE Yes Yes Yes Yes Yes Yes
DO-ENDDO Yes Yes(6) Yes(6) Yes Yes Yes
CASE Yes No No No No No
Bit functions (8) Yes Yes Yes Yes Yes
Array arithmetic Yes No No No No No
Record structures Yes No No No No No
Recursion Yes Yes Yes Yes No No
Dynamic allocation Yes No No Yes No No
Libraries
Graphics Yes Yes Yes Yes Yes No
Mouse Yes Yes Yes Yes No No
DOS interfaces Yes Yes Yes Yes Yes Yes
String processing Yes Yes Yes Yes Yes Yes
Command line Yes Yes Yes Yes Yes Yes
(1). Requires Phar Lap tools (not supplied).
(2). Uses standard DOS tool (not supplied).
(3). Uses standard DOS tool (not supplied). Also supports dynamically
linked libraries with tool provided.
(4). Uses Mini-make, which provides partial function.
(5). Supported in 2.20 release.
(6). Includes an indefinite loop (counterless) extension.
(7). Still requires a statement number.
(8). Bitwise operators included in syntax.
116 COMPUTER LANGUAGE % MAY 1990
---------------------------------------------------------------------------
TABLE 2.
Compiler performance
Microsoft Lahey Lahey OTG Microway SVS
F77 F77L F77L EM/32 FTN77 NDP F77
#1: Library
Compile (min:sec) 16:50 9:44 10:40 2:02 34:18 (1)
Build (seconds) 20.24 17.03 18.02 13.82 13.74 (1)
Librarysi2e (bytes) 84,323 72,704 85,504 25,680 45,568 -
#1: Null program
Compile (seconds) 13.34 8.49 14.83 1.79 37.38 20.70
.OBJ si2e (bytes) 244 451 454 193 152 (2)
.EXE si2e (bytes 2,443 13,116 11,161 288 78,829 12,200
#2: Euler test
Compile (seconds) 17.72 9.95 19.46 10.07 45.61 40.87
.OBJ Si2e (bytes) 1,169 1,353 1,496 773 1,208 (2)
.EXE si2e (bytes 31,672 36,572 33,309 784 82,867 72,232
Exe time (seconds) 19.70 22.04 29.05 60.59 44.43 60.31
#3: Matrix invert
Compile (seconds) 16.25 9.86 18.01 3.40 44.47 29.16
.OBJ si2e (bytes 1,036 1,190 1,308 772 1,005 (2)
.EXE si2e (bytes) 25,620 49,308 46,472 816 80,862 51,140
exe time (seconds) 19.24 23.48 35.60 68.66 55.39 59.93
(1) SVS F77 could not compile constructs used in library routines.
(2). No .0BJ files created.
---------------------------------------------------------------------------
Results and conclusions The conclusions of this review appear more clearcut
than usual. The answer seems obvious: if your programs can fit in 640K,
don't bother with protected-mode compilers, 386 or not. Microsoft, even
running 8086 code, will blow your doors off. Buy either Microsoft or Lahey
F77L.
If language features were the only issue, Microsoft would win hands-down.
Its language extensions offer significant power. This compiler should have
special appeal for those already familiar with M and CodeView. Once
Microsoft gets the bugs out, this should be a nice package, but I'd wait
for the next release.
For ease of use, friendliness, fast compilation, and the generally high-
quality, professional nature of both the compiler and the people who
produce it, you can't go wrong with Lahey. My money rides with them.
If you must have the extended RAM space, your choice is between Lahey F77L-
EM/32 and OTG FTN77.
For sheer speed and sleekness, the OTG compiler stands out like a Ferrari
among Yugos. It's an exciting, innovative, and high-quality product that
lets you use all of the power of the 386, without having to buy OS/2or
complicated and expensive D0S extenders.
But if execution speed is an issue, the Lahey product should get the nod.
Going with Lahey also gives you the advantage of an upward migration path
from F77L, and presumably later version of F77L-EM/32 will include the
editor and other tools F77L already has.
As for the Microway and SVS compilers, the less said the better. -
Jack W. Crenshaw holds a Ph.D. in physics from Auburn University in Alabama
and is an aerospace engineer at Honcywell Inc., Clearwater, Fla. He has
been writing software since 1954 and has been an avid computer hobbyist
since 1974.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The November 90 issue of Comp Lang contains a letter from Lahey
himself and D. Vallance for FTN77/386 that provides results for
their own benchmarks with Microsoft's version 5. Their results
are not consistent with Crenshaw's.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Marcell (@watserv1.waterloo.edu:bat...@watsci.waterloo.edu) wrote
the following:
I use Watcom Fortran 386. Actually , I was a beta tester even
before it was released for beat testing. I find it to be quite
good. I port applications from a SGI Power IRIS 4D to my 30MHz
PC frequently and I haven't had any problems. I also use there C
compiler and with there new 386 C compiler I can easily link
Fortran and C code together to produce, for example, data
acquisition software with data analysis routines. The packages
from Watcom use the same Linker, Debugger, Profiler, Library tool
..etc. All you need are the compilers and the libraries.
I have found there support to be excellent. I also use Borland
and Microsoft products and I get nowhere near the satisfaction.
Maybe I am a little biased, because I have friends at Watcom, but
I tend to be a little more demanding since I know what they can
do.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Frank Warmerdam (ra...@watcgl.waterloo.edu\!frank) wrote:
I work for a Advanced Scientific Computing Ltd., and I have
tested out the WATCOM F77/386 compiler briefly on behalf of a
roommate of mine that works at WATCOM. He successfully compiled,
linked an ran a fortran program with over 2.5 Meg of source code.
There where a couple of problems with one of the source files
which was over 1 Meg in size, however WATCOM immediately fixed
the problem, and after that there was no problem.
While I have not used this compiler for development, I have used
other WATCOM development tools, ie WATCOM C, WMAKE, WVIDEO, WLIB,
WLINK for personal C use and they form a very powerfull and
fairly friendly environment. As well I have found the company
very quick at fixing obscure bugs in the past and would recomend
their PC line of products as professional quality.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Three respondents liked the Lahey compilers.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Now for my own remarks:
Nine months ago I purchased FTN77/386 expecting that it would:
1. Allow me to create larger programs than will run under plain
DOS
2. Allow my exsiting programs to run faster
In the event I obtained a system that is truly excellent for
development purposes. Compilation and linking under FTN77 is
much much quicker than with the Microsoft compiler I also use. I
have used FTN77 to recompile two commercial programs that I
acquired (they normally sell for many thousands of dollars) that
were developed on other platforms. FTN77 allowed my to find
numerous bugs in these codes that had never been picked up on the
systems they were created on (VAX under VMS and PC with MS
FORTRAN). In the event I was left wondering how those programs
had ever worked in the first place. I am also able to create
larger applications programs than before. However, the FTN77
compiled versions of my programs do not run any quicker than the
MS FORTRAN compiled versions of programs that both compilers will
handle.
I have tested a program for solving multicomponent distillation
problems. This is a fairly typical chemical engineering
application and there are many methods for doing these
calculations. I am using a method in which all the model
equations are solved simultaneously by a multidimensional
Newton-Raphson based method. In the test problems identified
below the numbers of equations go from around 50 (small) to
around 600 (large). The equations themselves include several
thermodynamic properties and these are quite time consuming to
calculate. The major program bottlenecks are the thermodynamic
properties and the equation solving. The thermodynamic
properties involves lots of vector calculations as well as
transcendental functions (DEXP and DLOG being very common). The
equation solving part is mostly array arithmetic (matrix/vector
multiplications, solving many small linear subsystems of
equations). There is a small amount of reading and writing to
files and to the screen but by far the bulk of the computer time
is spent "number-crunching". The entire program is about 10,000
lines broken into about 200 subroutines and functions. Most of
these modules are used in other programs as well.
Here are some test results:
Problem MS FTN77
Small 5 9
Medium 36 38
Large 143 145
All times are in seconds and were obtained with FTN77 Versions
1.67 and 2.20 and MS FORTRAN 4.01 on a Zenith Z-386 operating at
16 Mhz (0 wait states). The machine has 3 Mbytes of extended
memory and an Intel 80387 math coprocessor. The DOS version is
3.3.05. After I ran these tests I acquired MS FORTRAN version
5.0 but I have not re-run the tests.
The point I would like to make is to remind those of you that
have read this far is that the only benchmarks that have any
validity are their own programs. The kind of program used in
many compiler comparisons should not be used to conclude that
that is how your own program will perform. If at all possible,
evaluate a compiler by using it on your own programs before
purchase.
In conclusion, I would like to see a proper review of WATCOM's
new FORTRAN compiler for 386 machine's. Is Walt Brainerd reading
this far? Would this be a suitable topic for the Fortran Journal?
Ross Taylor
Department of Chemical Engineering
Clarkson University
Potsdam, NY 13699
David Tholen
> Results and conclusions The conclusions of this review appear more clearcut
> than usual. The answer seems obvious: if your programs can fit in 640K,
> don't bother with protected-mode compilers, 386 or not. Microsoft, even
> running 8086 code, will blow your doors off. Buy either Microsoft or Lahey
> F77L.
It should be pointed out that Microsoft's product is also a protected-mode
compiler, namely for OS/2. Under that operating system, FORTRAN programs
have access to nearly 16 Mbytes. Under MS-DOS or OS/2 real mode, 640 kbytes
is the limit, as mentioned above.
An IBM representative mentioned to me that although the initial release of
the OS/2 version 2.0 SDK included only a 32-bit C compiler, the subsequent
release also included a 32-bit FORTRAN compiler. Apparently not Microsoft's,
so I don't know whose it is, if in fact one exists. I wouldn't be surprised
to see a couple of 32-bit compilers released shortly after OS/2 version 2.0
makes its debut, so there may soon be an alternative to these DOS extender
products.
Doug McDonald
>Ross Taylor writes:
>
>> Results and conclusions The conclusions of this review appear more clearcut
>> than usual. The answer seems obvious: if your programs can fit in 640K,
>> don't bother with protected-mode compilers, 386 or not. Microsoft, even
>> running 8086 code, will blow your doors off. Buy either Microsoft or Lahey
>> F77L.
>
AND it uses no arrays larger than 64K AND it is heavily floating point
dominated then the Microsoft compiler wins. BUT if you have a big
array, OR you have a program dominated by 32 bit INTEGER arithmetic,
then a real 32 bit compiler will win, even for small programs. I have
shown this with tests using Microsoft and MicroWay compilers.
Doug McDonald