Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!uflorida!codas!mtune!mtgzz!mtgzy!mtuxo!homxb!genesis!hotlr!dkc
From: dkc@hotlr.ATT (Dave Cornutt)
Newsgroups: comp.unix.wizards
Subject: Re: Scientific computing under Unix (was Re: Help us defend ...)
Message-ID: <199@hotlr.ATT>
Date: 7 Mar 88 17:04:43 GMT
References: <1636@tulum.UUCP> <20268@bu-cs.BU.EDU> <10729@cgl.ucsf.EDU>
Reply-To: dkc@hotlr.UUCP (Dave Cornutt)
Organization: Not much, but I'm working on it
Lines: 63

In article <10729@cgl.ucsf.EDU> seibel@socrates.ucsf.edu.UUCP (George Seibel%Kollman) writes:
 > In article <20268@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:
 > >
 > >Unix is the premiere system for compute intensive areas, such as the
 > >sciences using Fortran. The reason is the vast range of power a
 > >program written to run under Unix presents. As I said, a program
 > >developed on a small, affordable PC or workstation can be copied and
 > >re-run on huge compute engines.
 > 
 > but here's the point:  If Unix *is* going to be the hot banana for cpu
 > intensive simulation work, it's going to need good fortran support.  The
 > BSD attitude way back when was apparently something like "lets give them
 > a really lousy fortran compiler!  Then maybe fortran will just go away!"
 > Well, now there are a whole lot of people who think that Unix is not the
 > way to go for their work.  We have a Public Relations problem here, and
 > better fortran support will help win over a lot of people who make the
 > buy decisions.

You hit the nail on the head.  It's not that Unix isn't capable of
providing a good environment for Fortran usage, but that few vendors have
bothered to do it.  Why?  I'm not sure.  Maybe Unix vendors are just
assuming that they aren't going to get enough of that market to make it
worth their while.  It's true that there are some who will still be using
their 370's and their ancient Fortran 66 code a century from now, but I
think that there is a large market that would like to move over to Unix --
if vendors can provide them with good optimizing compilers, debuggers,
and most important, *good support*.  Remember the discussion on comp.lang.c
last year about people who were trying to move their number-crunching
over to Unix and finding out that the floating-point library routines
were dismal, and that their vendors *just didn't care*?

I used to do some serious Fortran number crunching when I worked at Gould,
and it worked out pretty well.  We ported over code that had originally
been written to run under Gould's MPX operating system to UTX (their
version of Unix, a dual-universe 4.3 and SysV system -- we used 4.3).
We compiled using their f77 (much improved over the one that comes from
Berkeley), and our applications went like gangbusters on our PN9000.
They have even better compilers coming down the road.

So yes, there's no reason why Unix can't support Fortran stuff, provided
that vendors have their arms twisted sufficiently.  Maybe this would be
a good market for some third-party software house to get into (or maybe
some already have that I don't know about).  It kind of reminds me of
the argument that Unix isn't a "user-friendly" operating system --
it isn't that the OS isn't capable of supporting slick menu-driven
systems if that's what you want, but that people have confused a
surface attribute (the shell) with a fundemental characteristic.
And by now, anyone that reads this group should know that shells
are as changable as laundry.

So, when we do the next VMS vs. UNIX round, let's not argue about
shells or editors or about whose compilers can lick whose daddy.
Let's look into more fundemental things, into design philosophy
and marketing strategy.  Let's look into kernel vs. user-space
code, into bundled vs. unbundled software, into multi-vendor
vs. single-vendor solutions.

(My personal belief is that Unix comes up the winner.)
-- 
Dave Cornutt, AT&T Bell Labs (rm 4A406), Holmdel, NJ (Note new address!)
UUCP:{ihnp4,allegra,cbosgd}!hotly!dkc (path stolen from Shelley)
"The opinions expressed herein are not necessarily my employer's, not
necessarily mine, and probably not necessary"