p4.tex

MPICH是MPI的重要研究,提供了一系列的接口函数,为并行计算的实现提供了编程环境.

\item[TC_2000] BBN TC-2000

\item[TC_2000_TCMP] BBN TC-2000 with the TCMP message-passing library

\item[IPSC860] Intel IPSC/860 (nodes only)

\item[IPSC860_SOCKETS] Intel IPSC/860 with socket libraries on the nodes

\item[DELTA] Intel DELTA 

\item[PARAGON] Intel Paragon

\item[TITAN] Stardent Titan

\item[SGI] Silicon Graphics workstations

\item[CRAY] Cray X/MP

\item[FX8] Alliant FX/8

\item[FX2800] Alliant FX/2800 or FX/800

\item[FX2800_SWITCH] Alliant FX/2800 or FX/800, with CAMPUS HiPPI switch

\item[KSR] Kendall Square KSR-1

\item[CM-5] Thinking Machines' CM-5

\item[SP1] IBM SP-1 with TCP interface to either Ethernet or switch

\item[SP1_EUI] IBM SP-1 with IBM's EUI interface to the switch

\item[SP1_EUIH] IBM SP-1 with IBM's experimental EUI-H switch interface

\item[MEIKO_CS2] Meiko Computing Surface

\end{description}

\end{ifinfo}

\begin{iftex}
\begin{tex}
\begin{tabular}{l l}
{\tt SUN} & Sun-3, Sun386i, Sparc-1, Sparc-2, or Sparc-10 workstations \\
{\tt SUN\_SOLARIS} & Sun workstations running Solaris \\
{\tt HP} & HP workstations \\
{\tt DEC5000} &  DEC 5000 workstations \\
{\tt ALPHA} &  DEC Alpha workstations \\
{\tt NEXT} &  68030- or 68040-based NeXT workstations \\
{\tt RS6000} &  IBM RS 6000 series workstations \\
{\tt LINUX}  & IBM-compatible PC's running the LINUX operating system \\
{\tt IBM3090} &  IBM 3090 running IBM's version of UNIX, AIX \\
{\tt BALANCE} &  Sequent Symmetry shared-memory multiprocessor \\
{\tt SYMMETRY} &  Sequent Symmetry shared-memory multiprocessor \\
{\tt SYMMETRY\_PTX} &  Sequent Symmetry shared-memory multiprocessor PTX OS \\
{\tt MULTIMAX} &  Encore Multimax shared-memory multiprocessor \\
{\tt GP\_1000} &  BBN GP-1000 \\
{\tt TC\_2000} &  BBN TC-2000 \\
{\tt TC\_2000\_TCMP} &  BBN TC-2000 with the TCMP message-passing library \\
{\tt IPSC860} &  Intel IPSC/860 (nodes only) \\
{\tt DELTA} &  Intel DELTA  \\
{\tt PARAGON} & Intel Paragon \\
{\tt TITAN} &  Stardent Titan \\
{\tt SGI} &  Silicon Graphics workstations \\
{\tt CRAY} &  Cray X/MP or C-90 \\
{\tt FX8} &  Alliant FX/8 \\
{\tt FX2800} &  Alliant FX/2800 or FX/800 \\
{\tt FX2800\_SWITCH} &  Alliant FX/2800 or FX/800, with CAMPUS HiPPI switch \\
{\tt KSR} &  Kendall Square KSR-1 \\
{\tt CM5} &  Thinking Machines' CM-5 \\
{\tt SP1} & IBM SP-1 with TCP interface to either Ethernet or switch \\
{\tt SP1\_EUI} & IBM SP-1 with IBM's EUI interface to the switch \\
{\tt SP1\_EUIH} & IBM SP-1 with IBM's experimental EUI-H switch interface \\
{\tt NCUBE} & Ncube \\
{\tt MEIKO\_CS2}  & Meiko Computing Surface \\

\end{tabular}
\end{tex}
\end{iftex}

\noindent
For example:
\begin{example}
make all P4ARCH=SYMMETRY
\end{example}
\noindent
The \code{all} is optional, for example
\begin{example}
make P4ARCH=SYMMETRY
\end{example}
\noindent
This will create a machine-dependent \file{Makefile} in each subdirectory,
make the p4 library, and compile and link a subset of the examples.

To add a new machine type, or to change the characteristic parameters
associated with an existing one, you can edit the file 
\file{p4/util/defs.all}.

To save disk space, various intermediate object files can be removed with
\begin{example}
make clean
\end{example}
\noindent
The system can be restored to its original, machine-independent state with
\begin{example}
make realclean
\end{example}
\noindent
Note that this removes the machine-dependent Makefiles in each directory, so
the operation is not idempotent.

\noindent
It is also possible to install (or clean) only some of the directories:
\begin{example}
make all P4ARCH=SUN DIRS=messages
make clean DIRS='monitors messages'
\end{example}
\noindent
To install only the Makefiles in all subdirectories, use:
\begin{example}
make makefiles P4ARCH=<machine>
\end{example}
\noindent
To install the necessary library and include files in a
directory everything that is needed to compile and link p4 programs, 
do:

\begin{example}
make install INSTALLDIR=<dir>
\end{example}
\noindent
This will create a p4 directory in \code{<dir>}, build a
minimal set of directories, copy the relevant \file{.a} and \file{.h} files
into it, and test the installation by mking a small set of examples.

\cindex{testing}
\xref{Getting Started} for instructions on how to run some example
programs after you have installed p4.

\node Installing the Documentation, Examples included with the Distribution, Installing the p4 System, Installing p4
\subsection{Installing the Documentation}
\cindex{documentation}
\cindex{man pages}
\cindex{online help}

The directory \file{p4/doc} contains this manual as well as files that
require installation.  This manual was prepared with the
\code{latexinfo} package from GNU emacs.
The files in \file{p4/doc} are:

\begin{description}
\item[p4.tex] the latex source for this manual, which uses the latexinfo style

\item[latexinfo.sty, titlepage.sty] the style files needed to latex this manual

\item[p4.html] an html version of this manual, suitable for being installed
   in your World Wide Web pages.

\item[p4.txt] plain ascii text of the manual, in case nothing else works.

\item[p4refcard.ps] postscript version of a reference card

\item[p4.1] unix man page for the p4 library

\item[p4f.1] unix man page for the Fortran interface to p4

\item[fiber] status of the work on direct fiber channel

\end{description}

The Postscript version of this manual is available by anonymous \code{ftp}
from \code{info.mcs.anl.gov}, in the directory \file{pub/p4}.  The file to get
(in binary mode) is \file{p4-manual.ps.Z}.  There is also a paper there giving
an overview of p4, in \file{p4-paper.ps.Z}.  This manual is also available
through the World Wide Web at
\code{http://www.mcs.anl.gov/home/lusk/p4/p4-manual/p4.html}.


\node Examples included with the Distribution,  , Installing the Documentation, Installing p4
\subsection{Examples included with the Distribution}
\cindex{examples}

A good way to see how various p4 functions are used is to look at the example
programs included in the distribution.  The \file{p4/monitors} directory
contains shared-memory examples written in C that use monitors, including one
instrumented with ALOG.  The \file{p4/messages} subdirectory contains
message-passing examples written in C.  The programs in \file{p4/messages_f}
are Fortran message-passing examples, and the \file{p4/contrib} and
\file{p4/contrib_f} directories contain a number of miscellaneous examples
contributed by users.  In each directory there is a \file{README} that
describes the individual examples.


\node Getting Started, Specifying Processes in the Procgroup File, Installing p4, Top
\section{Getting Started}
\cindex{getting started}

The easiest way to get started with p4 is to play with some of the
sample programs provided with the system.




\begin{menu}
* A Message-Passing Example::
* Program Description::
* Analysis of the Program::
\end{menu}

\node A Message-Passing Example, Program Description, Getting Started, Getting Started
\subsection{A Message-Passing Example}

We will begin with a message-passing example in the sub-directory named
\file{p4/messages}.  The code for the program is in the files \file{sr_test.c}
and \file{sr_user.h}.


\node Program Description, Analysis of the Program, A Message-Passing Example, Getting Started
\subsection{Program Description}

As the name implies, this program is an example of p4's send/receive
functionality.  Briefly, it is a simple program that runs a master
process and some slave processes.  The master and the set of slaves
form a ring of processes in which the master reads a message from stdin
and sends a copy of the message to the first slave, which passes it on;
the last slave passes the message back to the master.  If the master
receives an undamaged copy of the message, it assumes that all went
well, and reads another message.  Note that the ring of processes is a
logical structure in which each process assumes that its
predecessor in the ring is the process with the next lower id, and
its successor is the process with the next higher id.  The master
has id 0 (zero) and has the process with the largest id as its
predecessor.



\node Analysis of the Program,  , Program Description, Getting Started
\subsection{Analysis of the Program}

The first executable p4 statement in a program should be:
\begin{example}
p4_initenv(&argc,argv); 
\end{example}
\noindent
This initializes the p4 system and allows p4 to extract any command
line arguments passed to it, e.g. debugging parameters.  

Similarly, the last executable p4 statement in a program should be:
\begin{example}
p4_wait_for_end(); 
\end{example}
\noindent
This waits for termination of p4 processes and performs some cleanup
operations.

The procedure \code{p4_get_my_id} returns the unique integer id assigned
to the calling process by p4.

The statement:
\begin{example}
p4_create_procgroup();
\end{example}
\noindent
reads a procgroup file that the user builds and creates the set of
slaves described in that file.  Obviously this statement must be
executed before any slaves can be assumed to exist.  This procedure
is the method you must use to create processes that do message-passing.

The procedure \code{p4_clock} returns an integer that represents
wall-clock time in milliseconds.  It is typically used to retrieve the
time before and after some work, the difference representing the time to
do that work.  Note that there is also a \code{p4_ustimer} that is useful on
those machines that support a microsecond timer.

The procedures \code{p4_send} and \code{p4_sendr} are two of several 
p4 procedures that are available for sending messages to other processes.
They take as arguments the message type, the id of the "to" process,
the address of the message, and the message length.

The procedure \code{p4_recv} receives a message from another process and
sets the values of all four parameters.  \code{P4_recv} will automatically
retrieve a buffer in which to place a received message, thus
\code{p4_msg_free} may be called to free that buffer when it is no longer
needed.

The procedure \code{p4_num_total_slaves} is one of several procedures that
the user can invoke to determine information about the current execution.

To run this program, you need to create a procgroup file that describes
where all slave processes are to be executed 
(\xref{Specifying Processes in the Procgroup File}).  We will assume that
you have an example procgroup file (named \file{sr_test.pg}) in the 
\file{p4/messages} directory, and can run \code{sr_test} by merely typing:
\begin{example}
sr_test
\end{example}
\noindent
If the procgroup file is elsewhere, then you must type:
\begin{example}
sr_test -pg  {\it pathname_of_procgroup_file}
\end{example}

\noindent
Another example that is made by default is the program \code{systest}.  It
tests a number of the message-passing features of p4.


\node Specifying Processes in the Procgroup File, Developing a Simple p4 Program, Getting Started, Top
\section{Specifying Processes in the Procgroup File}
\cindex{procgroup files}

The procgroup file is the only portion of the interface that is very likely to
change through multiple versions of p4.  As new architectures are supported,
it is hoped that we can merely alter the procgroup file format to reflect any
new features.  (Of course new procedure calls may also be required, but
existing procedure calls will remain unchanged when possible).  See
\xref{Running p4 on Specific Machines} for a discussion of machine
dependencies in starting p4 programs.

The current format of a procgroup file is as follows:
\begin{example}
local_machine  n [full_path_name] [loginname]
remote_machine n full_path_name [loginname]
  .
  .
  .
\end{example}
\noindent

In some situations, the program is started via some
special command executed from the host machine.  In such cases, the
procgroup file name can be specified to the special command line along
with the program name (see for example the \code{runcube} and \code{rundelta}
shell scripts in the \file{p4/messages} subdirectory).  In those cases 
where no special command is required, no special handling is required 
for the procgroup filename.

The first line of a procgroup file may be ``local n'' where n is the number
of slave processes that share memory with the master.  The full path
name on the ``local'' line is ignored on machines other than cube and mesh
machines, and the IBM SP-1.  The word ``local'' may be replaced by an alias
for the local machine if needed, to specify an alternative transport layer.
The subsequent lines contain either three or four
fields:
\begin{enumerate}
\item
the name of a remote machine on which slave processes are to be created.
\item
the number of slaves that are to be created on that machine, 
i.e. be in the same cluster (note that on machines that support it, 
the processes in a cluster will share memory)
\item
the full path name of the executable slave program
\item
optionally, the user login name on the remote machine, if different from 
that on the host machine.
\end{enumerate}

As an example, let's assume that you have a network of three Sun 
workstations named sun1, sun2, and sun3.  We will also assume that you 
are working on sun1 and plan to run a master process there.  
If you would like to run one process on each of the other Suns, then you 
might code a procgroup file that looks like:

\begin{example}
    # start one slave on each of sun2 and sun3