[ HPF Home | Versions | Compilers | Projects | Publications | Applications | Benchmarks | Events | Contact ]

---

Next: VIEW Directive Up: High Performance Fortran Journal Previous: Overview

Input/Output

High Performance Fortran has exactly the same Input/Output facilities that are available in Fortran 90.

One of the High Performance Fortran Forum working groups was dedicated to I/O extensions for parallel machines. The objective was to define a set of extensions to standard Fortran 90 I/O which would provide high I/O performance on a massively parallel computer running HPF.

Three proposals in this spirit were offered. The basic idea of these proposals is outlined here and the proposals themselves appear in Section 13.

The HPFF voted not to include I/O extensions in the first version of the language. Arguments for this position include:

• I/O systems on parallel computers from different vendors are too architecturally different for there to be a useful abstraction on which the language model can build. For example, consider the difference between a machine with disks on each node, compared with one which has a high bandwidth disk system connected to the communication network, and thus globally accessible.
• Fortran I/O is already highly expressive, some would say too expressive.
• The HPF compiler must already know when it is performing I/O on distributed arrays, and can optimize the I/O to distributed files without any extensions to the source language.
• The management of distributed files (and their implementation) is a matter for the operating system, not the language.

Moreover the current lack of extensions does not limit features that may be added by system vendors. In particular:

• Vendors are allowed to implement any I/O extensions to the language they may wish. Indeed this would be impossible to prevent. There are simply no special I/O mechanisms mandated by HPF.
• The HPF run-time system may use whatever facilities the operating system provides for accessing ``high performance'' files, though the HPF language contains no I/O extensions that specifically describe such access. For example, the HPF system is entirely free to place a status='SCRATCH' file in the highest performance file system it likes, and distribute it as is appropriate for the machine, but it is not up to the user to say all this.

The proposals made to the I/O subgroup were based on the following observations:

• A massively parallel machine needs massively parallel I/O;
• Efficient programs must avoid sequential bottlenecks from processors to file systems; and
• Fortran specifies that a file appears in element storage order; this conflicts with striped files (for example, an array distributed by rows may be written to a file striped by columns).

The proposals were that HPF should provide explicit control to obtain high performance I/O. In essence the three proposals were:

1. On a write, give a hint about how the data will be read.

   !HPF IO_DISTRIBUTE * :: a WRITE a, b, c When an array is written, it can be easily read back in the given distribution. The annotation can be associated with either the declaration or the write itself; in the first case it applies to all writes of the array, while in the second it only applies to the one statement. The intent is that metadata is kept in the file system to record the ``right'' data layout. The advantages of this proposal include notation and efficiency.

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''; the proposal is to use FILEMAP. The programmer can align/distribute FILEMAP (on I/O nodes), associate FILEMAP with a file on OPEN, etc. There are no changes in semantics or file system.

3. Introduce parallel read/write operations that are not necessarily compatible with sequential ones.

   PWRITE a PREAD a Data can be read back only into arrays of the same shape and mapping. Data written by PWRITE must be read by PREAD. This solution does not need metadata in the file system or changes in the file system but is incompatible with the standard READ and WRITE.

Next: