Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!jato!vsnyder From: vsnyder@jato.jpl.nasa.gov (Van Snyder) Newsgroups: comp.lang.fortran Subject: Re: Fortran 90 status Message-ID: <1991Apr30.014552.19136@jato.jpl.nasa.gov> Date: 30 Apr 91 01:45:52 GMT References: <1991Apr24.202115.16119@dragon.wpd.sgi.com> <123207.25873@timbuk.cray.com> <1991Apr26.210247.17264@ariel.unm.edu> <1266@argosy.UUCP> Reply-To: vsnyder@jato.Jpl.Nasa.Gov (Van Snyder) Organization: Jet Propulsion Laboratory, Pasadena, CA Lines: 52 In article <1266@argosy.UUCP> ian@bear.UUCP (Ian L. Kaplan) writes: >>Second, the >>discussion on efficiency continues to skirt what I would regard as the >>major issue in scientific computing - parallelism. What about Fortran >>Extended is going to improve performance on parallel systems, of whatever >>type? >>-- >>John K. Prentice john@unmfys.unm.edu (Internet) >>Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA >>Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA ...[stuff deleted] > With the exception of experimental languages like SISAL, Id and >Lucid, I don't know of any languages that would work well across a >range of MIMD machines. C++ was mentioned. However, I suggest that >some though should be given to how "parallel C++" would be mapped onto >both shared memory (e.g., Alliant or Sequent machines) and distributed >memory (e.g., cubes) MIMD machines before making such claims. ... > Ian Kaplan > MasPar Computer Corp. It's nice to see at last some more folks concluding that dataflow languages hold more promise for MIMD machines. The problem with languages born of sequential computing, and then modified to try to cope with MIMD computing is that it's almost impossible to do the time & data dependency analysis a priori. Putting in BARRIER and PARDO won't be much help if you leave an important one out: it doesn't much matter how effectively your program uses the processors if it unpredictably gets subtly wrong answers. BTW, Dave Culler, the author of the Id compiler at the Computation Structures Group at MIT, now at Berkeley, has an Id -> C translator, and is working closely with Ncube to improve the message-passing stuff in their OS, presumably to take advantage of the fact that messages in dataflow context are of fixed length. With his hacked-up prototype, he's taking about 3-10 times as long as a C program to do the same computation, but still about 3-10 times as fast as an equivalent lisp program. Once he gets a REAL compiler cranked up on something like an Ncube, the enormous quantities of unstructured parallelism, as compared to the puny amounts of structured parallelism, in typical math software should make MIMD a real barn burner. And a lot easier to program than using a bastardized sequential language. Just my opinion. -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp