seibel@cgl.ucsf.edu (George Seibel%Kollman) (03/02/88)
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. Barry, thanks for an excellent posting overall, but I have to comment on the fragment above. Our research group does mainly heavy number crunching and related code development, mostly in fortran. I've developed scientific applications in fortran on seven different flavors of unix, and *none* of them had a compiler or debugger as good as the ones found on VMS in terms of efficiency of generated code, helping pinpoint bugs in user code, and being bug-free themselves. Unix provides an excellent software development environment in general, *if you know how to use it*, but it tends to be lacking in fortran support. After the fourth or fifth time you've spent hours hammering on some fortran bug under Unix, only to find it five minutes after porting the whole mess to VMS, your opinions start to get colored, ya know? If you think this is another "VMS is better than Unix" posting, relax. I'll still take my Sun/Convex any day, thanks, 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. George Seibel UCSF
shocking@nswitgould.OZ (Stephen Hocking) (03/07/88)
in article <10729@cgl.ucsf.EDU>, seibel@cgl.ucsf.edu (George Seibel%Kollman) says:
Lots of stuff here about fortrans etc etc
: ..................... 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.
:
: George Seibel
: UCSF
I'll agree with that. I'm running Microport Unix at home, and the f77
is mindboggling. Mind you, even the f77 on the Amdahl here (under UTS)
is not all that brilliant. When you're trying to port a small linear
programming package (~7000 lines), or CSMP II the fortran bugs really
start coming out of the woodwork. And when sdb (or the code generator) wont
cope with the -g option on large files, then the tears really start to flow.
I have gotten them running, and they run reasonably respectably, (it's
marvellous what a difference an 80287 makes!) about the speed of an
11/750 as far as I can see. Some of the bugs in the large model f77
library under Microport (AAAAAGGGH), but we coped.
Stephen
--
"I'll drink to that - Whatever it is.."
UUCP.net: {ukc,mcvax,ucb-vision,uunet}!munnari!nswitgould.oz!shocking
ACS.net: shocking@nswitgould.oz {ARPANET,BITNET}: Who knows?dkc@hotlr.ATT (Dave Cornutt) (03/08/88)
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"
kai@uicsrd.csrd.uiuc.edu (03/12/88)
F77 is slow, slow, slow. If you want fast, fast, fast fortran for scientific
computing, use Alliant's FX/FORTRAN. We're talking FAST! Very VAX/VMS Fortran
compatible. Bucks per megaflop, can't be beat.
Patrick Wolfe
pwolfe@kai.com
..!{uunet,ihnp4}!uiucuxc!kailand!pwolfe
I speak for myself.deke@socrates.ee.rochester.edu (Deke Kassabian) (03/15/88)
In article <43200014@uicsrd.csrd.uiuc.edu> kai@uicsrd.csrd.uiuc.edu writes: >F77 is slow, slow, slow. If you want fast, fast, fast fortran for scientific >computing, use Alliant's FX/FORTRAN. We're talking FAST! Very VAX/VMS Fortran >compatible. Bucks per megaflop, can't be beat. Well if your code lends itself to vectorization and concurrency, this is true. But Alliant FX/FORTRAN requires an Alliant FX computer...not for everyone. >Patrick Wolfe >pwolfe@kai.com >..!{uunet,ihnp4}!uiucuxc!kailand!pwolfe \\\ Deke Kassabian, URochester Department of Electrical Engineering \\\ \\\ deke@ee.rochester.edu "I never metacharacter \\\ \\\ or ...!rochester!ur-valhalla!deke I didn't like......" \\\
irf@kuling.UUCP (Bo Thide) (03/16/88)
In article <43200014@uicsrd.csrd.uiuc.edu> kai@uicsrd.csrd.uiuc.edu writes: > The f77 on HP-UX seems to be very fast. Our tests show that it is just as fast as C. In fact, the possibility to use single precision (32 bit) floating numbers in HP FORTRAN makes it even faster! So we were always very happy with it. Is there anybody who has a different opinion or has made a comparison between the HP FORTRAN compilers and others? We're curious to know since we are looking for max speed (at min cost). Just to give an example: A recent cross-spectral analysis program takes 36 hours to run on our smallest HP (220 with HPs old FPA)! -- >>> Bo Thide', Swedish Institute of Space Physics, S-755 90 Uppsala, Sweden <<< Phone (+46) 18-300020. Telex: 76036 (IRFUPP S). UUCP: ..enea!kuling!irfu!bt
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (03/17/88)
In article <1187@valhalla.ee.rochester.edu> deke@ee.rochester.edu (Deke Kassabian) writes: | | In article <43200014@uicsrd.csrd.uiuc.edu> kai@uicsrd.csrd.uiuc.edu writes: | >F77 is slow, slow, slow. If you want fast, fast, fast fortran for scientific | >computing, use Alliant's FX/FORTRAN. We're talking FAST! Very VAX/VMS Fortran | >compatible. Bucks per megaflop, can't be beat. [ I think Encore and Convex would argue that point ] | | Well if your code lends itself to vectorization and concurrency, this is true. | But Alliant FX/FORTRAN requires an Alliant FX computer...not for everyone. One of the points against multi-processor computers vs uni-processor, given that both have the same total power, is that some programs just don't allow more than one processor to be used. In those cases the uni-processor, with a faster processor, will run much faster, assuming that there is CPU available. This applies only to machines where there is available CPU. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
rick@soma.bcm.tmc.edu (Rick Gray) (03/22/88)
In article <43200014@uicsrd.csrd.uiuc.edu> kai@uicsrd.csrd.uiuc.edu writes: > >F77 is slow, slow, slow. If you want fast, fast, fast fortran for scientific >computing, use Alliant's FX/FORTRAN. We're talking FAST! Very VAX/VMS Fortran >compatible. Bucks per megaflop, can't be beat. > >Patrick Wolfe >pwolfe@kai.com >..!{uunet,ihnp4}!uiucuxc!kailand!pwolfe > >I speak for myself. Masscomp's f77 compiler is also very fast. we've ported a few pretty large VAX/VMS FORTRAN programs for curve fitting to our Masscomps with minimal difficulties. We've also written (neural) circuit simulations in Masscomp f77 and found it to be very robust-- fast at compiling & running and a good interface to C system routines. -- Rick Gray uucp: {rice,shell}!soma!rick Program in Neuroscience arpa: rick@soma.neuro.bcm.tmc.edu Baylor Col. Med., Houston, Tx 77030
edw@pinot.zehntel.com (Ed Wright) (03/27/88)
My trusty DEC book says the approach to use is:
Turn on your teletype and turn the round switch to line.
Hold the control key down and press the C key , let both up.
FOCAL will respond with "?01.00*"
your on you own after that :-)
ed wright
Never try to teach a
>>>>>> ucbvax--\ pig to sing. It wastes
>>>>>>>> sun -->----zehntel !edw>/dev/null :-) your time and it
>>>>>> varian--/ and it annoys the pig.