Subject: (anti**3)-proposal for I/O

From: [email-masked]
Date: Tue, 8 Sep 92 18:23:06 CDT

> From: Piyush Mehrotra <[email-masked]>
> Subject: An anti-anti-proposal for I/O
> Date: Tue, 8 Sep 92 16:39:32 -0400
>
> An Anti-Anti-I/O-Proposal:
>
> 
> There is some sentiment that nothing needs to be added to FORTRAN 90 I/O.
> However, we perceive this as a problem, since FORTRAN 
> enforces a sequential ordering (the column-major ordering)
> on the data elements that are written out.  The point is
> that relaxing this ordering may allow the compiler
> and/or runtime system to optimize the input/output
> operations.
>
> ...
>

But, I don't think that the physical layout of the bits on the disk(s)
has to be in FORTRAN order.  Rather, if a ``sequential style'' access
is made to the file, then the bits are returned in FORTRAN order.

I *expect* the compiler, the run-time system, and the file system to
collude in order to exploit distributions in order to provide high
performance I/O.  I *expect* the subsystems concerned with I/O to
keep ``hidden'' data on the in-processor data distribution.  The
distribution information for an HPF object is passed whenever a
a routine call is made, so it's not a secret...  The system knows
where it's I/O resources are, so I don't understand why the programmer
should have to spell out any more information.  It's not a language
issue.

> Secondary storage is used for two purposes:
> a) to temporarily store scratch data which is later
> reused in a program, and
> b) to communicate data to other programs (which includes 
> display to user).
>
> In the first case, it is possible that the compiler can analyze
> the program and figure out that the ordering can be relaxed.
> However, in the second case it is only the user that can 
> provide any hints about the subsequent usage of the data.

``Scratch'' files that have no lifetime beyond the execution of
a program can be arbitrarily crazy inside.  But files that persist
should be available for normal access by regular F77 or F90 or HPF
programs. 

> ...
> Barbara Chapman
> Piyush Mehrotra 

Peter