(j3.2006) [MPI3 Fortran] Feedback from Fortran J3 meeting

[Van Snyder]

On Fri, 2008-05-30 at 14:22 -0600, Keith Bierman wrote:
> On May 30, 2008, at 1:46 PM   5/30/, Van Snyder wrote:
> 
> >
> >
> > It was at the February 1997 meeting at the Sunrise Suites, at which I
> > proposed to allow user hooks into the I/O process in paper 97-114.  I
> > gave several reasons for wanting to allow users to process I/O at the
> > lowest level, including MPI/PVM.
> >
> >> I/O tends to be pretty slow; on the other hand exposing the inner
> >> workings of the I/O library is often an exercise in pain (and might
> >> constrain future internal evolution).
> 
> Then I think the issue was the complexity of imposing "imposability"  
> on existing implementations (many of which were considerably more  
> complex than the Univac V library. Indeed, JPL even  had their own  
> NAMELIST implementation at one point ... I recall working in the lab  
> late one night when the author was tweaking it (Dan, last name I've  
> forgotten, who had gone blind by that time ... it was amazing how he  
> could keep page after page of code in mind, make changes via a semi- 
> literate high school assistant :>)
> >
> > For purposes of the present discussion, it could be limited to
> > unformatted I/O, or described in a form that makes it clear that
> 
> Even imposing upon unformatted I/O might be complex on some kinds of  
> systems (variations of memory mapping, multi-processors with  
> dedicated "I/O" units).

The hooked routines wouldn't do "I/O" in the Fortran sense.  Rather,
they would do stuff that could be posed as I/O at the programmer's
level, i.e., reasonably accessed by read, write, flush and wait
statements, e.g., MPI, PVM, ....  How the processor actually does its
"real" I/O would be irrelevant.  Dedicated "I/O" units wouldn't be a
problem if the existence of "hooks" were not a changeable mode, i.e., if
you could only specify hooks while opening a new connection.

"Imposability" shouldn't be a problem, either, if the processor only
looks to do things in the way specified by the user when it notices
hooks inserted for a particular "connection" by an OPEN statement.  For
other connections, it continues to do things its own way.  Compiler and
RTL guys can advise whether this needs something in the control list on
more statements (probably only read and write), than just the OPEN
statement.  One way to do it would be to use the object containing the
hooks in place of the unit number.  The processor would then see an
extension of a standard-specified derived type, instead of an integer,
which could trigger an entirely different code-generation strategy.

If we were to provide these hooks, and encourage encapsulating MPI, PVM,
etc... transactions under I/O, the problems we are currently pondering
concerning code motion would be subsumed under ASYNCHRONOUS.  We
wouldn't have to worry whether SYNC MEMORY interacts with ASYNCHRONOUS
or VOLATILE or BLORTZ.

-- 
Van Snyder                    |  What fraction of Americans believe 
Van.Snyder at jpl.nasa.gov       |  Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or
disapproved by JPL, CalTech, NASA, the President, or anybody else.