Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!ncar!bierstat.scd.ucar.edu!morreale
From: morreale@bierstadt.scd.ucar.edu (Peter Morreale)
Newsgroups: comp.lang.fortran
Subject: Re: Missing the whole point (the Fortran vs. C debate)
Message-ID: <9424@ncar.ucar.edu>
Date: 6 Dec 90 17:46:12 GMT
References: <28548@usc> <185951.1857@timbuk.cray.com> <TMB.90Dec5014523@bambleweenie57.ai.mit.edu> <1990Dec5.182145.2639@ariel.unm.edu>
Sender: news@ncar.ucar.edu
Reply-To: morreale@bierstadt.scd.ucar.edu (Peter Morreale)
Organization: Scientific Computing Division / NCAR, Boulder Co.
Lines: 85

In article <1990Dec5.182145.2639@ariel.unm.edu>, john@ghostwheel.unm.edu (John Prentice) writes:
> 
> Of couse, Cray Fortran has had constructs (the CDIR directives) for telling
> the compiler to vectorize a loop since the beginning.  However, in general
> I agree.  

    The Cray Fortran compilers will vectorize *every* loop (which meets
    vectorization criteria) by default.  The programmer doesn't need to
    make any modifications to his code.  (although most do to obtain
    increased performance, but non-portable constructs are not used or
    needed)

> With regard to expressing parallelism, the people at Myrias had
> the easiest expression in Fortran that I have encountered yet.  If you
> wanted a parallel do-loop, you said pardo instead of do.  That was it.  They

    Sounds like a very non-portable construct.  The Cray method of
    obtaining parallelism is to add directives which appear as Fortran
    comment cards.   The directives are interpreted by source code
    analyzers and translated into system calls.

> It is a pity because they were way ahead in terms of making it easy to
> express parallelism in higher languages (at least that is my impression,

     With the Cray utility "cf77" I need only specify a flag on the
     command line and I get parallelism introduced into my portable
     code.

     The Cray method is to (with the proper command line flags...) run
     the portable Fortran through various filters which eventually
     re-write the source code with the proper system calls, which is fed
     into the compiler.  Seems very easy for the user.  

     Of course, to increase performance of the code, I would look at the
     source code translation and tune it accordingly.
> 
> I don't know how Cray does parallel constructs.  But I hardly know anyone
> who tries to do serious parallel programming on the Cray.  Unless you are
> among the chosen few who can get dedicated Cray time, it is not cost effective.

     Hummm...  I do question this statement.  If I am executing a code
     on a Cray which only runs for a few minutes, you bet, it's not cost
     effective.

     How about ocean and climate models which run for literally
     *hundreds* of Cray CPU hours?  (say a thousand wallclock hours) If
     I can reduce the turnaround time by a factor of 3 or 4, 6, is it
     worth it?  If I can, perhaps I can increase the resolution of the
     model in the first place.  Does better science result from
     increased resolution?   In addition, I get 64bit results on the
     Cray for every calculation in single precision mode.  Is this
     important?

     In the Cray, I can get subroutines, and/or do loop iterations 
     passed across multiple CPUs.
    
> We tried it on the Cray 2 and on the YMP a couple years ago.  We were rarely
> able to get all the processors at one time.  Also, you don't have very
> many processors.  

     So?  On a Connection machine with 64k processors, you only get the
     parallel region of the code executed on those processors.  The
     serial portion of the code is excecuted on a front-end.  For a
     highly parallel code, you get good results, for a "typical" user
     code, you get front-end speeds.  

> 
> If C provides more natural ways to express parallelism, then that would
> be a major claim in its favor!  I would be very interested to hear more
> about this.
> 

     I'm not a C wizard, but I suspect that with the heavy reliance of
     pointers, it would be difficult to exploite parallelism within the 
     language.  How would you update pointers consistently amongst CPUs?

-PWM

(Comments are my own, no-one else's....)
------------------------------------------------------------------
Peter W. Morreale                  email:  morreale@ncar.ucar.edu
Nat'l Center for Atmos Research    voice:  (303) 497-1293
Scientific Computing Division     
Consulting Office
------------------------------------------------------------------