Professor Norm Matloff
Dept. of Computer Science
University of California at Davis
Davis, CA 95616
(Please mail any questions to Norm Matloff.)
Whether you are installing PVM yourself or it is already installed for you, you must set have ~/.cshrc set your environment and path correctly before using or installing PVM.
Use setenv to set the following variables:
$PVM_ROOT this is the directory containing bin, lib, include, examples, src, etc. (if you are installing PVM, this is the directory created when you unpack PVM) $PVM_ARCH this is your platform, e.g. SGI5, Linux, etc. (use all-capital letters; see the subdirectory names in $PVM_ROOT/conf))
Your path must contain the following directories:
$PVM_ROOT/lib $PVM_ROOT/lib/$PVM_ARCH $PVM_ROOT/bin/$PVM_ARCH ~/pvm3/bin/$PVM_ARCH
You must create that last directory; it is the default place PVM looks for your PVM application binaries. (PVM also looks in $PVM_ROOT/bin/$PVM_ARCH.)
Installation is extremely easy; just type "make" at the Unix shell prompt while in the directory $PVM_ROOT.
If you do not have m4 on your system, the PVM install will complain, but you can fix this just by removing the f components in the Makefile and Makefile.aimk.
A central concept in using PVM is the "console," a program named pvm. It is used to configure your PVM virtual machine (i.e. the set of machines on which you will be running PVM applications), to initiate and monitor application program executions, and so on.
You invoke the console by typing "pvm" at the Unix shell prompt, and exit it by issuing the console's quit command at the console prompt.
The console includes online help. Type "help" to see a list of topics, and type "help x" for help with topic x.
By the way, the console's command-line reader allows "scrolling" backwards in the command list, with ctrl-p meaning to go back to the previous command, as with many Unix shells. The editing is done using arrow keys and ctrl-d to delete a character.
First, make sure you can execute rsh on the machines you wish to run PVM on.
To run PVM application programs, the PVM daemon, pvmd, must be running on all machines where you will be using PVM. When you first invoke the console, it will start the PVM daemon on the machine from which you do the invocation. To then start the daemon at other machines, use the console's add command.
For instance, suppose I first invoke the console from the machine sgi12. If I then issue the command
add sgi8 sgi10
to the console, it will start the PVM daemon at the machines sgi8 and sgi10, so that your virtual machine would now consist of sgi8, sgi10 and sgi12.
You can always check which machines the daemon is currently running on by using the console's conf command.
If you wish to avoid using the console (because you are having trouble with rsh , or gdb can't attach to a running process on the machines you are using), you can run pvmd by hand, in the background, on each machine. You will have to write your program so that the call to pvm\_spawn() specifies the host name for each machine you run the program on.
Make sure to have a line
in your source file. For information on PVM library functions and an example PVM application program, see Professor Matloff's main PVM page and his PVM example program, respectively.
The PVM package includes the aimk shell script to help you compile PVM applications. However, instead of that, I suggest that you simply put the following alias into your .cshrc file:
alias pvmcc "gcc -g -o ~/pvm3/bin/$PVM_ARCH/\!* -I$PVM_ROOT/include \!*.c -L$PVM_ROOT/lib/$PVM_ARCH -lpvm3"
(On Solaris systems, you will probably need to add -lsocket to the end of this command.) To compile a program, say, app.c, just type
Note that this will place the binary app in your directory ~/pvm3/bin/$PVM_ARCH.
For simplicity, we will assume here that you have written your program as an "single program, multiple data" (SPMD) application. This means that the same program runs at all nodes, as with spmd.c in the directory $PVM_ROOT/examples. By contrast, another style is to write a "manager" program which runs on one node, and a "worker" program which runs on all the other nodes; the programs master1.c and slave1.c in that directory exemplify this approach.
SPMD happens to be our personal preference, and in PVM there is also an interesting advantage: SPMD programs do not call the pvm_spawn() function and thus are simpler to write. Instead, the spawning is actually done from the console.
Suppose our application program source file is app.c, and the executable is app. Suppose also that we wish to run on the three SGI machines in our earlier example. Then at the console we would type
spawn -3 -> app app's_command_line_arguments
This would run 3 copies of app, at the 3 machines.
The "->" means to send the output to stdout at the console. (Note: You many need to hit the Enter key an extra time.) If I had wanted the output to go to a file, say z, the command would have been
spawn -3 ->z app app's_command_line_arguments
By the way, the command
spawn -4 -> app app's_command_line_arguments
would still work; on one of the machines, two copies of app would run.
What about your output? Note carefully that all the output from printf() calls will be collected by pvmd at whichever machine you started the console. These may be interspersed together from different nodes, making your output difficult or impossible to read. For this reason, make sure the node number is printed in each call to printf(). For example, instead of
printf("x = %d\n",x);
printf("output from node %d: x = %d\n",mynode(),x);(Note: This interspersing of printf() outputs is quite common in parallel systems.)
To use gdb with PVM, follow the instructions in my parallel debugging guide.
When you are done with your various PVM runs, you can kill the daemons on all nodes by re-entering the console and issuing the halt command.
Dr. Matloff's PVM example program (SPMD style) is available; click here.