Parallel I/O requirements - reported by Alok Choudhary The first issue was a survey of what the vendors are doing. Intel - (CFS/PFS) To get parallelism explicitly, special routines provide various was to access the data. There is file striping on a file system basis.
Thinking Machines found the need for 64 bit file pointers. They have made an effort to get parallelism from Fortran I/O. Meiko - Like INTEL has striping controlled on files system basis with read/write distributed arrays. IBM - Vesta: File distributions may be specified.
Guy Steele described the extensions for 64 bit integers as the most difficult thing they experienced at Thinking Machines. Fortran provides most needs, depending on the file location. If one Fortran program writes and another program reads, there may be a mismatch between the number of processors, and the number of disks. Then there are some implications requiring some unscrambling but Fortran I/O spells this out. Part of the reason this works is that the disks are not node attached, they are all are equally distant from the processing nodes.
At this point, the report was interrupted with some informal discussion that went approximately as outlined here. Rob Schreiber asked if implementations can just add keywords. Alok: - adding file layout directives doesnUt harm portability because they can be ignored. Guy: Thinking Machines has another set of primitives that are accessed from message passing where all processors are dealing with the same file, but in an asynchronous fashion - also routines to control what happens when all processors are trying to write. These are low level things not visible to Fortran. Jerry Wagener: you need to write things out to be read back in other programs / different configurations. Is there a way to aid the system getting this right? Should we have something like a specification of the number of streams on the reads / writes? Alok: you should always maintain a specific global view of the data - and map in various applications.
Returning to the Parallel I/O report: Summary of Types of I/O identified are: out-of-core (persistent), checkpointing and restart, real-time output, I/O for very high bandwidth (massive amount of I/O) .
Some additional issues are: Is the language sufficient or some additions needed? Can a runtime library do the job? What is the model for parallel I/O? Are there special issues for I/O over high-performance networks?
Bob Knighten noted that users aren't interested in parallel I/O, they want high performance. Mary raised the question of the need for standardization of buffered I/O for overlap of computations with I/O. Bob: Posix has standards for this. Ken: it might be useful to adopt these as part of HPF.
Ken asked if there are simple changes that should be considered such as 64 bit integers, posix I/O, or an out-of-core directive. He invited a simple proposals.
Terry Pratt: overlap of I/O and computations may be a key issue. Guy: we are not necessarily promoting 64 integers. Chuck: F90 already has a KIND mechanism.