Hardware Reference
In-Depth Information
one-file-per-process I/O method. This method is easy to program and requires
no MPI communication. However, it results in a large number of files that are
hard to manage. Another drawback is that the same number of processes
must be used to read the files as the parallel program that created the files.
Otherwise, additional effort is required, such as determining the mapping of
files to processes and the logical data layout from files to memory (most likely
noncontiguous in file space). Due to these concerns, it is desirable to store
data in a canonical order in files such that the mapping is independent of
the number of processes. The second method of performing I/O addresses
this limitation, and it involves funneling all I/O through one process of the
program. All I/O requests are forwarded to that process and carried out there.
Obviously, this approach can result in poor performance for large jobs due to
communication congestion and limited memory space available in one process.
The third method, parallel I/O to a shared file, overcomes the limitations
of both approaches. In this method, all processes open a common file and read
or write different parts of the same file simultaneously. This approach main-
tains the logical view of a single file and can also result in high performance
given sucient I/O hardware, a parallel file system, and an ecient MPI-IO
implementation. The following sections describe how MPI-IO can be used to
perform this form of parallel I/O eciently.
13.2 Using MPI for Simple I/O
Based on the third method described in Section 13.1.2, high performance
parallel I/O can be achieved by enabling all processes to read or write to
different parts of a single shared file. Figure 13.2 shows a simple example of
such a program. Overall, this code is not much different from how one would
do it using regular POSIX I/O. It simply uses the MPI-IO equivalents of
POSIX
open
,
lseek
,
read
, and
close
functions.
MPIFileopen
takes an MPI communicator as the first argument, which
represents the group of processes that will access the file. The second ar-
gument is the file name. MPI does not specify the format of the file name;
implementations are free to specify the format. For example, in some cases,
the user may need to prefix the file name with an implementation-specified
string (such as
nfs:
) to specify the type of file system on which the file is
located. In many cases, implementations may be able to determine the type
of file system automatically, without the prefix. The third argument indicates
the mode of access, in this case read only. The fourth argument provides users
with a way to pass \hints" to the le system that may improve performance.
In this simple example, the default set of hints are used (
MPIINFONULL
);
Section 13.4 will describe how to pass hints. The file handle is returned as
the last argument. It is used in all future accesses to the file.
MPIFileopen
