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
mg@goanna.OZ (Mike Gigante) (03/02/86)
We have a number of locally built 68k unix(v7 + BSD enhancements) machines here.
The fortran supplied with the machine (f77) is woefully inadequate. After
deciding we needed an alternate compiler to f77, we obtained the SVS product.
(silicon valley software). We have found this to be a *marked* improvement
to our version of f77. The compilation time, execution time and the memory
usage of the SVS compiler are substantially better than f77. Figures for
a matrix manipulation program are given below.
The minus for SVS fortran is that it has a very primitive debugger (compared
to say sdb & dbx). It adheres to the Fortran 77 standard very closely,
enforcing clauses that are not usually enforced (e.g. no mixing of character
data with other types in named common). This often means a little more
effort is required in program conversion; not all fortran programmers are
strict in there usage of standard fortran :-) .
Program 1. The program 'display' from BYU-MOVIE.
(Only compile time is compared since there are a few problems with the
compiler that caused a bum executable.)
SVS f77
19.5 minutes 66.5 minutes /* no optimization under f77 */
Program 2. Forsythe, Malcom & Moler 's 'decomp' & 'solve' for random
matrix of order 50.
a) double precision
SVS f77 f77 -O
compile 34 sec 131 sec 164 sec
run 41 sec 100 sec 98 sec
b) single precision
SVS f77 f77 -O
compile 30 sec 129 sec 156 sec
run 21 sec 99 sec 97 sec
in comparison, on a vax 750 under 4.2BSD,
compile 48 sec 127 sec
run (single) 8 sec 5.5 sec
(double) 10 sec 8 sec
I may not be talking about the most commonly available machines
but this is still software (the f77 compiler) that was *sold*
commercially as part of a standalone supermicro!!
I'm not sure which machines SVS is available for, nor their address
(off the top of my head). For 68k machines, I can recommend it highly.
Mike Gigante
Royal Melbourne Institute Of Techology
Melbourne, Australia.mg@goanna.OZ (Mike Gigante) (03/02/86)
I forgot to mention that f77 effectively forces you to split your programs into many small files when you are on non-virtual machines. Otherwise, as(1) will grow almost exponentially in memory size. You also run into a message something like 'too many external symbol names - try -Nx option'. Unfortunately, our f77 knows no such option :-) (this was in f77pass1) On virtual machines, you'll start to notice very high page rates for large files/routines. SVS's memory requirements are relatively constant & small. Mike Gigante RMIT, Australia
rcodi@goanna.OZ (Ian Donaldson) (03/02/86)
> I forgot to mention that f77 effectively forces you to split your > programs into many small files when you are on non-virtual machines. .... > Mike Gigante I agree with most of Mike's responses (its a wonder no-one else has submitted such an article yet), but the last point re: f77 forces you to split your prog into small files - is true, but this is not a BAD idea! The whole concept of compilation under UNIX has been to allow the Make utility to maintain large programs by arranging for minimal recompilation. C programs are also broken into managable segments of source. The speed of the {f77,c,pc} compiler is not THAT critical if this philosophy is observed. You tend not to do this as much with Pascal as there is no universal standard way of doing separate compilation (ps: despite this, I am a Pascal freak). It is still nice to have a fast compiler, for the times you are compiling someone else's code and don't want to spend too much time porting it. It would be nice if {ccom, f77pass1, pc0} all skipped the phases of generating assembly language text, and just produced a load-file straight from the source. I can see little advantage in producing text and then for the optimizer (c2) to parse it again, write it again, and for the assembler (as) to parse it yet again to finally produce a relocatable binary. Poor pc users are stuck with the following large number of passes in compiling programs: cpp, pc0, pc1 (f1), pc2, c2, pc3, as, ld. C programmers have this: cpp, ccom, c2, as, ld. It would be nice if it was just: cpp, ccom, ld. Even nicer if cpp was built into the input parser of each of the compilers (but still have it as a separate package too). A lot of the compilation time is spent doing unecessary disk i/o and parsing. I have heard that it has not been done this way due to the complications of porting it to a new machine. This argument does not really hold, as there are large amounts machine specific pieces of code in most of the passes anyway (ccom, pc, f77pass1, c2 and as all need to be extensively modified when porting to new cpu's). The only advantages that I can see of producing text assembly source is that it can be hacked by sed scripts to replace certain instruction sequences by others that the compiler doesn't generate, or to peruse the efficiency (or lack thereof) of the code. I agree with Mike's comments re: efficency of code generated by the compiler, though - its is far from excellent. This SHOULD be improved substancially without introducing extra compile time (this is probably not a job for the C optimizer either!) I tend to disagree with the philosophy of just using registers R0 and R1 for calculations, and assigning the rest for register variables. ALL intermediate results in calculations should be cached in registers. If the compiler can figure out what your code is doing, it might tend to lock SOME variables in registers to improve efficency (eg: for-loops that have constant range where the range is large, and known at compile time). I have looked at a lot of assembly code produced by various ports of UNIX C compilers and noted that there is little or no attempt to "carry over" intermediate results from C statement to C statement. The same goes for f77 and pc. What does YOUR compiler generate for the following C code? a = z[i,j,k]; b = z[i,j,k]; A good example of cost-effective local optimization can be found in the RMIT CYBER Pascal 3 compiler (an improved version of Univ. of Minnesota's V3 compiler courtesy R.S.V. Pascoe and Associates of RMIT Dept of Computing). The only thing that makes it unnecessarily slow is the CYBER's architecture - it is not a byte-addressable machine - most of the time is spent unpacking and packing words and characters. Also, there is no hardware stack, so one must be faked by "dedicating" certain registers. (I'm talking about th 60-bit emulation - the 64 bit emulation I'm not sure about due to lack of readily available documentaion on the instruction set -- and the general lack of ability to do much at all under NOS/VE unless you are a Fortran or CYBIL programmer - we are still waiting for a Pascal and C compiler from CDC) (side question - why did CDC put NOS/VE on their 64 bit emulation, rather than just porting UNIX to it, native? UNIX under another O/S would tend to leave a lot to be desired (such as speed). ) I might add that RMIT/Minnesota Pascal compiler does all this in 1 pass - source to relocatable binary! COMPAS/Turbo Pascal users are very pleased with this concept too. C does not really require more than 1 major pass either if you write your compiler sensibly. The CYBER is designed to crunch numbers, not characters and it does this very well. Pity a fair percentage of the (daytime) load on our CYBER is spent crunching characters by student compilations and packages. A VAX 8650 (running 4.3bsd) that has a set of compilers that generate CYBER machine code, along with a (transparent) fast channel link to a CYBER would be nice. Compile & edit on the VAX and execute on the CYBER, giving rise to many of these: :-) :-) :-) :-) . - DEC & CDC are you listening? Ian Donaldson, Dept of Comm & Elec Eng, Royal Melbourne Institute of Technology, Melbourne, Australia. VOICE: (03) 660-2619 (midday <= BestTimeToCallMe < midnight) :-) ACSnet: rcodi@Unison6.oz
mg@goanna.OZ (Mike Gigante) (03/02/86)
> > I agree with most of Mike's responses (its a wonder no-one else has > submitted such an article yet), but the last point re: f77 forces you > to split your prog into small files - is true, but this is not a > BAD idea! > > The whole concept of compilation under UNIX has been to allow the Make > utility to maintain large programs by arranging for minimal > recompilation. Actually, some times it isn't worth it. For movie (v5.2), there are hundreds of subroutines. After fsplit'ing and creating a makefile, I have found that up to 5 min cpu time (on 68k's) can be spent by make checking update times of file. There is a lot of disk traffic associated with this. It would be nicer to break the source into fewer,logically grouped subroutines/functions as we *ALL* do with C source files. Unfortunately, we can't do this with f77 as we either run out of memory or page the system to death (dep. on which sys). Some programs also have VERY large subroutines (someone else's code *of course*). Sometimes these can't be compiled under f77!! Mike Gigante, Mechanical & Production Eng. RMIT, Australia
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.ARPAmwm@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! <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
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