Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site python.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!pyuxww!pyuxv!nvuxa!nvuxb!nvuxr!nvuxd!python!michael
From: michael@python.UUCP (M. Cain)
Newsgroups: net.lang.f77,net.unix
Subject: Re: Wanted: Ultra-fast fortran compiler for UNIX
Message-ID: <153@python.UUCP>
Date: Mon, 29-Jul-85 09:20:25 EDT
Article-I.D.: python.153
Posted: Mon Jul 29 09:20:25 1985
Date-Received: Wed, 31-Jul-85 20:29:01 EDT
References: <621@astrovax.UUCP> <9871@Glacier.ARPA>, <426@carina.noao.UUCP> <131@hscfvax.UUCP>
Organization: Bell Communications Research
Lines: 23
Xref: watmath net.lang.f77:343 net.unix:5185

It is educational to consider the origins of the f77 program
when asking questions about why the code it produces runs so
slowly.  According to the original BTL documentation, the author's
real motivation was to have the first full '77 Standard compiler.
It was generated in a hurry using lex and yacc, and the I/O library
was thrown together very quickly.  I believe that it met the
author's goal, but the approach is not one that generally
leads to a production-quality compiler.

As a benchmark of the quality control, the distributed, "supported"
f77 that I used soon after I joined BTL had a bug in the format-free
input routines for floating point numbers.  It caused a value like
-1.2 to be stored as -0.8.  Why?  Because the minus sign was applied
only to the integer part of the number, and then the integer and
fractional parts were added together.  Fixing the source for this
routine not only made it correct, but reduced its size considerably.

My own experience is that recoding routines in C results in
a 30-35% improvement in speed -- about the same as people are
quoting for the VMS compiler.

Michael Cain
Bell Communications Research