[net.lang] Any decent Fortrans under Unix ? Which machine ?

laurie@cybavax.UUCP (Laurie Moseley) (02/20/86)

*** REPLACE THIS LINE WITH YOUR MESSAGE ***

		Fortran under Unix
		------------------

	My university is in the process of planning the replacement of two
central machines and there are two groups of users whose needs must be met.

1. Unix users
2. Heavy Fortran finite-element programmers

	The Fortran users are unwilling to consider an Unix solution because
they believer that Fortran performance under Unix is woefully inadequate. I
have heard many informal reports to this effect and it certainly seems to be
firmly embedded in the folklore of Unix.

	If anyone has experience of a Fortran running efficiently under Unix
I would be very glad to hear from them. Any performance figures would be
particularly welcome. Alternatively anyone who has tried Fortran-under-Unix
and been disappointed would be worth hearing from.

			Best wishes from South Wales

				Laurie Moseley
-- 
If you have skill, you have power.
If you have power, you need responsibility.
Never demonstrate one without the other.

guy@sun.uucp (Guy Harris) (02/23/86)

> 	The Fortran users are unwilling to consider an Unix solution because
> they believer that Fortran performance under Unix is woefully inadequate. I
> have heard many informal reports to this effect and it certainly seems to be
> firmly embedded in the folklore of Unix.

As are a number of other incorrect or misleading claims.  There is no such
thing as "FORTRAN performance under UNIX".  Which FORTRAN?  Which UNIX?
From what I can glean from some postings, DEC offers both the 4.3BSD "f77",
which is descended from the original UNIX "f77" but has had a lot of effort
put into optimization, and the VMS FORTRAN 77 compiler under ULTRIX.  The
latter probably offers excellent performance, and the former is probably
fairly good as well.  Sun has a FORTRAN which is also descended from the
original UNIX "f77", but which has had a new optimizer added; it is claimed
to offer comparable performance with VMS FORTRAN 77.  A number of the
"minisupercomputer" vendors have vectorizing FORTRAN compilers for their
UNIX.  I think Gould has brought up their own FORTRAN under their UNIX, and
I presume Apollo's FORTRAN is not "f77"-based and is fast.

On the other hand, if you get a PDP-11 and run the original "f77" that came
with V7, the performance will probably be dismal compared to, say, FORTRAN
IV-PLUS.  A lot of UNIX box vendors have probably put little effort into
software other than porting and some bug fixing, and probably have equally
low-performance FORTRANs.  ("f77" was originally done because Stu Feldman
wanted to see if you could do a FORTRAN compiler using the UNIX C compiler's
code generator - it was a research project, not a production compiler.)

The low performance of the original "f77"s generated code is probably what
gave rise to this folklore, but not all UNIX FORTRAN compilers are
"f77"-based and the "f77"-based ones from serious vendors have had serious
effort put into making "f77" generate high-quality code.

Tell the FORTRAN users that blindly believing folklore may require little
effort but doesn't bring very much in the way of rewards, either.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.arpa	(yes, really)

wcs@ho95e.UUCP (x0705) (02/24/86)

In article <3274@sun.uucp> guy@sun.uucp (Guy Harris) writes:
>> 	The Fortran users are unwilling to consider an Unix solution because
>> they believer that Fortran performance under Unix is woefully inadequate. I
>> have heard many informal reports to this effect and it certainly seems to be
>> firmly embedded in the folklore of Unix.
>
>As are a number of other incorrect or misleading claims.  There is no such
>thing as "FORTRAN performance under UNIX".  Which FORTRAN?  Which UNIX?
>.....[followed by good discussion of Fortran compilers]

The real issue your Fortran hackers should be worrying about isn't
performance (if they need MIPS, they can buy a Cray :-).  It's software
development support.  Unfortunately, there are two problems here:

	1) Most fortran hackers don't understand the question, much
		less know the tradeoffs of various systems.

	2) Those that do are used to *really complete libraries* that
		don't exist on the average Unix box.  They tend to say
		things like "Sure, there are good debuggers and
		interactive compilation is nice, but you expect I
		should rewrite EISPACK and IMSL when  I need them?".
		And they're right.  

If you need to support that community, you've got to give them the
library support they need so they can be productive.  IF you can't do
that, get a MicroVAX for them to work on in the daytime (while you run
UNIX on the real machine), and run VMS for them at night.  ( I got the
impression you were talking about VAX-sized machines.  If you're
talking about IBM-sized machines, run UTS in the daytime and VM at
night.)  Alternatively, find someone who makes a good library package, 
and force them into the twentieth century; real number-crunchers should
schedule their jobs to run overnight anyway because swapping/paging
will blow them away on a heavily loaded timesharing machine.

-- 
# Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs

bzs@bu-cs.UUCP (Barry Shein) (02/24/86)

Guy Harris makes some very good points, I would like to add a few, I
have dealt with this issue and folklore here, my response has become
very simple:

Those here that went with a vendor's proprietary systems because they
believed the fortran to be better remain on those systems to this day.

Those that went with UNIX (and a few that were willing to change over
having realized their mistake) have doubled and trebled (and, in one
case 12x) their performance by replacing their hardware with newer
hardware that is coming out mostly running UNIX. Some of these purchases
were fully funded by sale of the used equipment, all cost 1/3 or less
price of the equipment they were replacing (typically, a $250,000 mini-computer
for a $65,000 super-micro which was much faster.)

Two groups have specifically said that they have not taken advantage of
this because their fortran code has become too heavily dependant on the
vendor's proprietary hardware/software environment and they do not have
the personnel resources to switch over.

Don't make the same mistake, project your upgrade options for both
cases in the current context (as if you made this decision two years
ago.) I think the facts speak for themselves.

What good is it to have a great optimizer on a slow machine?

	-Barry Shein, Boston University

jwp@sdchem.UUCP (John Pierce) (02/24/86)

In article <3274@sun.uucp> guy@sun.uucp (Guy Harris) writes:
 > ...DEC offers ... the VMS FORTRAN 77 compiler under ULTRIX...

BSD people shouldn't get their hopes up:  a reasonably substantial rumor says
that DEC has deliberately fixed this so it will not run under BSD, and is not
going to make it available as a separate product.  A rather bizarre marketing
decision, but what can you expect from DEC?

 > ...I think Gould has brought up their own FORTRAN under their UNIX...

This appears to be true, but be a little wary.  During our recent cycle of
looking for a VAX replacement, the Gould calculated answers for the fortran
benchmarks that were different from everyone else's (and wrong).  That and
the virtual memory space limit (16Mb) were the two of the reasons for not
selecting the Gould.

				John Pierce, Chemistry, UC San Diego
				jwp%chem@ucsd.edu
				{decvax,sdcsvax}!sdchem!jwp

peters@cubsvax.UUCP (Peter S. Shenkin) (02/25/86)

In article <bu-cs.210> bzs@bu-cs.UUCP (Barry Shein) writes:
>
>Guy Harris makes some very good points, I would like to add a few, I
>have dealt with this issue and folklore here, my response has become
>very simple:
>
>Those here that went with a vendor's proprietary systems because they
>believed the fortran to be better remain on those systems to this day.

	This scarcely seems like an argument against those systems.  Maybe they
	stayed on them because they like them!

>Those that went with UNIX (and a few that were willing to change over
>having realized their mistake) have doubled and trebled (and, in one
>case 12x) their performance by replacing their hardware with newer
>hardware that is coming out mostly running UNIX.

	Depending on the hardware and the software, you have to ask whether
	their improvement might have been even greater had they run something
	other than UNIX on their new hardware.  Also, to double or treble
	performance starting with something whose performance is egregious
	is no great trick.

>Two groups have specifically said that they have not taken advantage of
>this because their fortran code has become too heavily dependant on the
>vendor's proprietary hardware/software environment and they do not have
>the personnel resources to switch over.
>
>Don't make the same mistake...

	That mistake cuts both ways.  f77 also has quirks unique to it which
	make porting to other machines difficult.  Fact:  it's hard to write
	portable code.  And at least one of the new and laudable advents in
	the UNIX Fortran world, the availability of DEC's native compiler under
	ULTRIX, will perpetuate (if that's what I mean) the problem (if it's
	a problem);  this Fortran has all the VMS-Fortran extensions (DO...
	ENDDO, etc.), which are different from the f77 extensions ("strings
	with double quotes like these", recursion, various argument 
	passing and output formatting quirks).  Some worlds, such as the
	molecular modeling world, are built around DEC Fortran.  Since most
	programs to do this kind of thing are in the range of 20-60K lines of
	source code, and are freely proliferated, in such worlds DEC Fortran
	(whose extensions I understand actually emanate from an old military
	spec!) has become the de facto standard.  In fact, at least some
	microsupercomputers running UNIX have vectorized Fortran compilers to be
 	compatible with source written for VMS Fortran.  As more good Fortrans
 	become available under UNIX, these features, and dependence on them, 
	will proliferate, willy-nilly.

	SUMMARY:  Now, at last, there are UNIX systems on which good Fortran
	compilers are available.  This is wonderful, and right now we're
	entering an era in which you don't have to eschew UNIX for lack of
	a good Fortran.  But let's remember that this has happened *only*
	within the past year, at the most, that the "classical" UNIX
	user still thinks of Fortran the way Lorenzo thought of the Dark Ages,
	and that the performance and reliability of -- let me play it safe -- 
	*almost* all Fortrans under *almost* all flavors of UNIX on *almost* 
	all machines has been depressing to contemplate through *almost* all
	of the history of UNIX.

	Peter S. Shenkin	 Columbia Univ. Biology Dept., NY, NY  10027
	{philabs,rna}!cubsvax!peters		cubsvax!peters@columbia.ARPA

kenward@mdivax1.UUCP (kenward) (02/27/86)

<<hi>>

I object to the idea that "really good libraries" are the only, or even the main
requirement for good Fortran software support.  Particullarily when discussing
UNIX f77.

First of all, a good, reliable, fully documented compiler is required.  The
very basic software support needed is good error checking, and intelligible 
error reporting at compile time and run time!  
("snark (magic2) compiler error" just doen't cut it)

Then there is the question of a good environment -- good, *user friendly*, 
edit-compile-run-debug support.  UNIX f77 just doesn't have it.  VAX VMS 
Fortran does.

In addition, the compiler should have a reliable, working optimizer, and the
resultant code should execute at an acceptable MIPS.  Many such Fortran 
optimizing compilers are currently available (VAX VMS, Perkin Elmer Fortran 77, MTS Fortran H, and there definitely many more I am not familiar with).  With 
the availability of superminis like those produced by DEC, Gould, or Prime, 
Perkin-Elmer, acceptable hardware performance can be obtained without buying a "Cray".  

Last of all, good library support -- at the Fortran source level -- beginning
with fundamental things like good I/O support (ie: parallel I/O, buffered I/O).
While it is a *pain*, it is usually easier to write a numerical routine from 
scratch than it is to try and write high level support for things like parallel
I/O.  IMSL is a luxury.

Just some thoughts, and certainly not the whole picture, but I hope you get the
gist of what I am trying to put across.


***
    Disclaimer:
      MDI wishes to inform anyone who would dare ask that they have NEVER 
      heard of me!
***

-- 

Gary W. Kenward
Mobile Data International Inc.
Riverside Industrial Park
Richmond, B.C.
Canada  V7A 4Z3

Plus ca change, plus c'est la meme chose!

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> SNAP! <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

geoff@desint.UUCP (Geoff Kuenning) (03/01/86)

In article <210@bu-cs.UUCP> bzs@bu-cs.UUCP (Barry Shein) writes:

> What good is it to have a great optimizer on a slow machine?

The problem people are forgetting here is numerical accuracy.  As Gene
Spafford pointed out a few months back, there are *no* current Unix
Fortrans that have numerically accurate libraries (I/O is, as usual,
especially weak).  Many people stick with their Cray, CDC, or DEC Fortran
because those companies have put many buckos into accuracy, unlike Bell
Labs who merely dabbled in it.  I have no doubt AT&T will eventually
correct this problem on the 3B line, but since it's highly machine-dependent
(is the 3B IEEE?) AT&T's good work will not automatically carry over to
all the private-hardware vendors.

What good is it to have a speedier machine if the answers are wrong?
-- 

	Geoff Kuenning
	{hplabs,ihnp4}!trwrb!desint!geoff

davida@umd5.UUCP (03/04/86)

> Plus ca change, plus c'est la meme chose!
 
Plus c'est la meme chose, plus ca change
(The more things stay the same, the more they change ... )  :-)   
 
Sorry, couldn't help it .....
-- 

David Arnold
University of Maryland
UUCP: { {allegra, seismo}!umcp-cs, ihnp4!rlgvax } ...!cvl!umd5!davida
ARPA:    davida@umd5.ARPA

mwm@ucbopal.BERKELEY.EDU (Mike (I'll be mellow when I'm dead) Meyer) (03/05/86)

In article <161@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes:
>The problem people are forgetting here is numerical accuracy.  As Gene
>Spafford pointed out a few months back, there are *no* current Unix
>Fortrans that have numerically accurate libraries (I/O is, as usual,
>especially weak).  Many people stick with their Cray, CDC, or DEC Fortran
>because those companies have put many buckos into accuracy, unlike Bell
>
>>	Geoff Kuenning

Interesting statement, especially considering that DEC is selling their VMS
FORTRAN compiler for Ultrix, and Cray provides CFT (the standard Cray
FORTRAN compiler) with Unicos. It appears that they have good libraries and
accuracy, except when they run under Unix :-).

	<mike

wagner@utcs.uucp (Michael Wagner) (03/06/86)

In article <518@ho95e.UUCP> wcs@ho95e.UUCP (Bill Stewart 1-201-949-0705 ihnp4!ho95c!wcs HO 2G202) writes:
> [ ... ]   If you're
>talking about IBM-sized machines, run UTS in the daytime and VM at
>night.)  
>
>-- 
># Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs


No need to do that.  They co-exist (that's part of the point).  And,
in fact, you probably want to submit to a VM batch subsystem (where
you can get EISPAK and all the other things you mentioned) and only
do the editing on UTS.  Oh, that AMDAHL would only see the light and
make a single-user UTS system, so they could peacefully co-exist
with VM...if you load up your UTS system too heavily, you will have
problems.

Michael Wagner (wagner@utcs)

geoff@desint.UUCP (Geoff Kuenning) (03/08/86)

In article <404@ucbjade.BERKELEY.EDU> mwm@ucbopal.UUCP (Mike Meyer)

catches me in a rather overblown and obviously unresearched statement:

>> As Gene
>> Spafford pointed out a few months back, there are *no* current Unix
>> Fortrans that have numerically accurate libraries...

I stand chastised;  in fact there *are* accurate Fortran compilers
available under Unix.  Mike mentions that

> DEC is selling their VMS
> FORTRAN compiler for Ultrix, and Cray provides CFT (the standard Cray
> FORTRAN compiler) with Unicos.

and he's right;  these are compilers that have been written carefully.
In DEC's case, this was done (at great expense;  VMS Fortran was
written in BLISS-32) because of f77's low quality.  The moral is that
you should be careful, but you *can* find a decent fortran under Unix.
(In the 68000 world I think fairly highly of Absoft's compiler, though
I'm not sure if they exist any more.)
-- 

	Geoff Kuenning
	{hplabs,ihnp4}!trwrb!desint!geoff

kenward@mdivax1.UUCP (kenward) (03/10/86)

Geoff Kuenning writes:
> 
> ...The moral is that you should be careful, but you *can* find a decent fortran under Unix.
> 
> 	Geoff Kuenning
> 	{hplabs,ihnp4}!trwrb!desint!geoff
> 

The question is, where?  Myself and a number of others have posted requests 
for information on a GOOD fortran compiler for unix.  A definite, useful 
answer has yet to appear (at least, that I have not seen any).  I am checking 
out the availability of VMS Fortran for unix, but even it is available (at a 
reasonable cost) it is a *new* port, and considering the difficulty others 
have had porting to unix, I have to be slightly pessimistic.
-- 

Gary W. Kenward
Mobile Data International Inc.
Riverside Industrial Park
Richmond, B.C.
Canada  V7A 4Z3

Plus ca change, plus c'est la meme chose!

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> SNAP! <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

ken@braegen.UUCP (Ken Marchant) (03/12/86)

> ...
> (In the 68000 world I think fairly highly of Absoft's compiler, though
> I'm not sure if they exist any more.)
> -- 
> 
> 	Geoff Kuenning
> 	{hplabs,ihnp4}!trwrb!desint!geoff

Does anyone else know if Absoft still exists, and if so how they can be
contacted. Does anyone have any comments on this or other decent fortran
compilers. I'm looking for one with good precision and good complex number
libraries to run on a 68000 machine. (Preferably Spectrix.).

-- 

			Ken Marchant
			The Braegen Group, Toronto, Ontario
	(ihnp4,decvax)!utzoo!mnetor!yetti!utrc-2at!braegen!ken

	The opinions of my employers may or may not be those presented
	here; you'd have to ask them, and they're not telling. 

	Toto, I have a feeling we're not in Kansas anymore.

mwm@ucbopal.BERKELEY.EDU (Mike (I'll be mellow when I'm dead) Meyer) (03/15/86)

In article <199@mdivax1.UUCP> kenward@mdivax1.UUCP (kenward) writes:
>Geoff Kuenning writes:
>> ...The moral is that you should be careful, but you *can* find a decent fortran under Unix.
>
>The question is, where?  Myself and a number of others have posted requests 
>for information on a GOOD fortran compiler for unix.  A definite, useful 
>answer has yet to appear (at least, that I have not seen any).  I am checking 
>out the availability of VMS Fortran for unix, but even it is available (at a 
>reasonable cost) it is a *new* port, and considering the difficulty others 
>have had porting to unix, I have to be slightly pessimistic.

Ah, it appears that you are asking a slightly different question than the
one Geoff is answering: he says that you can find a decent FORTRAN for Unix,
you are looking for one for Unix on a VAX. That severely limits your
choices.

Rumor (from "usually reliable sources") has it that part of the support for
the VMS/Ultrix FORTRAN is in Ultrix proper, so you won't be able to run it
on a non-Ultrix VAX. Solution: Buy Ultrix, of course. [Buying Ultrix may not
be as bad as you think. If you haven't looked at it seriously, don't laugh
about it.]

	<mike

bobbyo@celerity.UUCP (Bob Ollerton) (03/18/86)

I have held back on this discussion wanting to avoid being commercial,
but no one seems to be responding so:

My company builds a computer system using RISC architectures which is
designed to run large, ugly, interactive, number crunching,
Fortran programs such as mechanical CAE applications.

We started with the standard bsd F77 3 years ago
and have improved (fixed?) it to the point that its roots are 
difficult to trace.  

We frequently port programs is the hundreds
of thousands of lines with few if any problems.  For example,
Ansys, Nastran, Patran-2, and MARC have been ported and together totals
to over a million lines of code.

We have also fixed dbx to work with big programs and have added
many other "world class" development tools and features to
the compiler.  Our software releases usually ship with ZERO customer
reported compiler bugs!!!!

The good news is that I feel its got to be one of the
best fortran compilers on Unix, Even better news is that it comes
with our systems -  I don't know of a better Unix/Fortran system
anywhere else.  Our pricing starts at about what you would pay for 
a reasonably configured workstation, cost of ownership
is usually lower.

Oh, I work here so you might want to check what I say with some
of our customers.


-- 
Bob Ollerton; Celerity Computing; 
9692 Via Excelencia; San Diego, Ca 92126; (619) 271 9940
{decvax || ucbvax || ihnp4}!sdcsvax!celerity!bobbyo
                              akgua!celerity!bobbyo