Subject: I think that I'm subscribed now

From: "Jason Behm" <[email-masked]>
Date: Tue, 22 Sep 92 09:03:30 EDT

Organization: IBM Technical Computing - Kingston, NY USA
News-Software: UReply 3.0
X-X-From: Jason Behm
References:

I think that I'm subscribed.  (Now if only there were some discussion...)

Jason Behm
-------------------------------------------------------------------------
IBM Technical Computing           Internet: [email-masked]
MM5A/278 Neighborhood Road        Phone:(914) 385-1853, internal 695-1853
Kingston, NY  12401               FAX:  (914) 385-4372, internal 695-4372
-------------------------------------------------------------------------

---

From: Bob Knighten <[email-masked]>
Date: Tue, 22 Sep 92 08:51:15 PDT

At the last HPFF meeting, there seemed to be agreement that in this initial
version of HPF there will be *NO* language support for parallel I/O.  Below is
an excerpt/paraphrase from Chuck Koelbel's minutes on this topic:

Marc Snir offered a number of solutions (to the problem of supporting parallel
I/O) for consideration in HPF:

  Solution 0: Define no language extensions. (The compiler does it all) 
    Metadata can be stored with the file to specify its layout.
    Does this assume too much of the compiler and file system?  A
    (small) majority of the I/O subgroup thinks this is insufficient,
    since it puts lots of burden on the compiler/operating system.

  Solution 1: Define hints (annotations) that do not change file
    semantics, in the spirit of data distribution. (This gives some
    information to the compiler.)

  Solution 1.1 (Piyush Mehrotra): On write, give a hint about how the
    data will be read.

  Solution 1.2: Give hints about the physical layout (number of spins,
    record length, striping function, etc.) of the file when it is
    opened.

    This uses the HPF array mapping mechanisms. (A file is a
    1-dimensional array of records.) The syntax needs a "name" for the
    file "template": we suggest FILEMAP. The programmer can
    align/distribute FILEMAP (on I/O nodes), associate FILEMAP with a
    file on OPEN, etc. There are again no changes in semantics or file
    system.

  Solution 2: Introduce parallel read/write operations that are not
    necessarily compatible with sequential ones.

  PWRITE a
  PREAD a

There were straw polls to guide the I/O group.  A series of such polls was
expected, but the first poll found a count of 16 yes, 10 no, and 8 abstain in
favor of solution 0 (doing nothing, as opposed to any active solution).  Ken
Kennedy recommended that the subgroup come back in another round and provide
more functionality then. A recommendation was made and seconded that a
rationale for not handling I/O be added to the draft; some of the e-mail
discussions appeared suitable for this.

Robert L. Knighten	             | [email-masked]
Intel Supercomputer Systems Division | 
15201 N.W. Greenbrier Pkwy.	     | (503) 629-4315
Beaverton, Oregon  97006	     | (503) 629-9147 [FAX]