Subject: survey

From: [email-masked] (Mary E Zosel)
Date: Thu, 2 Apr 92 08:38:53 -0800

Group 1
FYI --- I sent the following survey out to a mailing list that probably
hits people at about 150 CRI sites, asking them to send email back to
me and Tom MacDonald.  ... Following the survey is the first response
back - an excerpt of a message from EPFL in Switzerland.
   -mary-

----

survey sent
----

Long Message - requesting input from users at your site who are 
interested in writing high performance Fortran applications, especially
those looking toward highly parallel machine and still wanting
portability. 

There will be discussion of this at CUG. But input from users at
your site is solicited, even if you will not be in Berlin. 

Send email to [email-masked] and [email-masked]  {Don't just reply to unicos-l}.

-------
-------
Background:
A group is currently meeting to discuss the definition of some standard
language extensions for "High Performance Fortran" - inspired by the
Fortran D project at Rice.  Most of the vendors for large parallel
systems are involved.

Initial goals include:
 > support for managing data placement (e.g. on distributed memories)
 > support for data parallel programming
 > support tuning codes for high performance
 > portability between "HPF" systems
 > preserve working serial version of code as much as possible
     (so a version can run on workstations, for example).
 > provide directives and some minimal syntax extensions (e.g. forall)
     to existing Fortran standards to facilitate tapping top performance
     for parallel machines
 > track Fortran 90 terminology, semantics, syntax, etc. whenever
      F90 definitions are available. {e.g. don't invent new incompatible
      things when F90 already has something}.
 > give users enough so they can rewrite once - rather than incremental
      improvements
 > keep it simple 
 
-----
The Issue: - How much Fortran 90?
-----
At the first working group meeting in March - there was considerable
discussion about how much, if any, of Fortran 90 should be defined to
be part of HPF. Customer surveys were suggested.

There are parts of F90 that no one objects to ... e.g. longer names,
mil-spec extensions, etc. --- everyone just assumes these are Fortran
and portable. There are parts of F90 such as allocatable arrays
which appear to provide important functionality for HPF.  There is the
F90 array syntax which provides a convenient way to express
data parallelism, but isn't ABSOLUTELY required, because smart 
compilers can analyze the triply nested loop and spot parallism.
There are things which are really unrelated, like Modules, Kind, etc.

------
The Choices:
------

There appears to be three approaches the working group can take:

(1) Define a separate F90 binding and a  pure F77 binding.
 
      PRO (1): This is the best way to support standards.  This allows
               HPF to use F90 features like INTERFACE as full features
               of the language.  This also provides a path for people
               who don't believe F90 will become widely available and
               want to stick with F77.

      CON (1): Users want HPF yesterday.  They don't want to wait until
               full F90 compilers are available before they can use
               HPF.   F77 is officially an archival standard. We
               should not be proposing new features.

(2) Define HPF with a minimal set of extensions from F90, but basically
       F77.  E.g. adopt memory allocation and maybe interface blocks
       to support redistribution of data across calls, but specifically
       do NOT include the array syntax.  Vendors can add it if they
       wish, but it is not required.

       PRO (2): This gives maximum compatibility with workstations, etc.
               while still providing useful new functionality.  This can
               be available fastest. Full array language requires
               compiler changes which will slow down availablity.

       CON (2): Users with experience using array syntax on 
               parallel machines like it.  Understanding parallel codes
               is hard enough. The  "clean" form of array syntax is a
               major help. However, if it is not part of HPF standard then 
               users interested in portability between parallel systems will 
               not be able to use  the array language unless all of 
               the vendors support it.

(3)  Define HPF with the subset of useful perfomance features from F90,
       including  array syntax.

       PRO (3): Users need this functionality now. Don't hold it up
                waiting for full F90 (where it will be part of the
                vendor's least mature product).  Send the vendors
                a message that this part of F90 is important. Full F90
                would be nice, but make this subset a priority. 
                Users who are willing to trust compiler
                parallelism technology in exchange for workstation
                compatibility can choose not to use the array
                syntax.

       CON (3): Full array syntax slows down the availability. It
                also encourages vendors to avoid putting the proper
                emphasis on top quality loop optimization which is
                also important for HPF.

-----
The opinions of your users who are potential customers of HPF are
solicited.  It will probably be a case of prioritizing the
options (with comments).

   -mary zosel-

-----
-----
----
response from epfl
----
----
Date    2.4.1992
Subject High Performance Fortran
From    Mark Sawley
To      Tom MacDonald
CC      Michel Jaunin, Marie-Christine Sawley, Mary Zosel

Subject:   High Performance Fortran
... (deleted part of message intended for Tom)
In our institute we have two types of users that are closely interested in the
development of HPF. The first type contains those that currently use F90 on
massively-parallel machines (CM and MasPar), while the second  those that are
presently developing codes for current and future generation high performance
computers.

The requirements of the first group of users is clearly to have available as
soon as possible a HPF that contains those elements of F90 that are currently
being used (e.g., array syntax and intrinsics, automatic array declarations,
etc.) There is not an immediate interest in other F90 features (such as, e.g.,
modules). This group of uses would thus strongly favour approach (3) listed in
the e-mail message of Mary Zosel.

The second group's requirements are slightly different. Since the thinking is
perhaps more long term, it would be of interest to have available more of the
F90 features, even if this means a longer compiler development time. Thus a
support of the full F90 standard would be beneficial, corresponding to approach
(1). At present this group is forced to write their code in F77, using a
structure that allows incorporation of F90 features when, and if, they become
available.

As it is pointed out, there is a strong argument against incremental
improvements of a compiler. However, it is hoped that the above two approaches
are not mutually exclusive, and that some staging of the compiler development
work will be undertaken.

Having worked personally with F90 based languages, I am pleased with a number
of the features (mentioned above) that distinguish it from F77. I feel that the
benefits inherent in F90 - in terms of both of functionality as well as
resulting code "cleanliness" - outweight the resistance to change. I would thus
hope that HPF would be something more than "basically F77".

I hope that the above comments give some impression of our views on HPF.

Best regards,

Mark