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