NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/parallel/2075

Text File | 1992-09-08 | 14.4 KB | 359 lines

Newsgroups: comp.parallel
Path: sparky!uunet!gatech!hubcap!fpst
From: [e-mail] (Martin Beaudoin)
Subject: pvm vs p4  (Summary of replies)
Message-ID: <[e-mail]>
Apparently-To: <[e-mail]>
Sender: [e-mail] (Netnews Admin)
Organization: Le laboratoire de robotique de l'Institut de recherche
    d'Hydro-Quebec
Date: Tue, 8 Sep 1992 12:52:27 GMT
Approved: [e-mail]
Lines: 345

A few weeks ago, I ask this newsgroup about the pros and cons of using
pvm versus p4. Since then, I received some very interesting replies
and also some "I am interested in the replies you will get, could you
post a summary please...".

So here it goes. I would also like to thank everyone who replied to my
question.

Martin Beaudoin                         [e-mail]
Institut de recherche d'Hydro-Quebec    [e-mail]
Varennes, QC, Canada   J3X 1S1          [phone]

-------------------------------------------------------------------------

From: [e-mail] (William Gropp)
To: [e-mail]
Cc:
Subject: Re: pvm vs p4
Date: Tue, 18 Aug 92 16:34:51 CDT

There are lots of differences between p4 and pvm.  Let me summarize and
then go into more details.

pvm is small and provides a simple way to pack several different types
(integers and doubles, for example) into a single message.  It is optimized
for a heterogenous environment.

p4 is larger than pvm and provides sends and receives, as well as a variety
of shared memory operations.

There are a number of technical details that you should know.  p4's
messaging model is implemented with a variety of services; for example,
on an Intel Touchstone, fast Intel-specific routines are used.  pvm's
implementations (to date) are all based on sockets.

PVM's implementation requires that data be copied one more time than
p4's (it has to be staged until the message buffer is flushed).  pvm also
uses a daemon on each processor, so that a message passes through 2
intermediate processes before reaching the destination process.  p4 sends
messages directly from sender to receiver; connections are opened as
needed.  In my tests on 2 SPARC IPX's, p4 was roughly twice as fast as
pvm.

Finally, there is the issue of ease-of-use.  My model of a parallel
job is

    foo -np 4 <other arguments>

where a sequential job is

   foo <other arguments>

Neither p4 nor pvm make this simple, but it is possible to support in p4
(I have code that you may be interested in).  Under pvm, there is currently
no way to interrogate the pvm daemon, making it impossible to just
connect to the daemon and run.  The pvm model seems to be

    generate a file of hosts
    start up a pvmd
    Move your program (or create a link) to where pvm expects to find the
       executable (p4 doesn't require the executable to be in any
       particular place).
    Start your job (note that pvm doesn't propagate the enviroment, such
       as command line arguments, working directory, and the like)
    (probably) kill the pvm daemon so that you can use pvm later.

You CAN avoid the steps of setting up and killing the pvm daemon ONLY if
you can use all of the machines that may be in the pvm set.  For example,
if I say that you can use my workstation only during certain times of day,
or only for jobs that are small and short, you'd need to create a special
pvm daemon for each such use.  Thus, you can only create a pvm daemon and
let it sit around if it is always acceptable to run jobs on any of the
processors the daemon knows about.  There has been some talk of using a
load-average monitor to improve this, but our experiance has been that
that is not sophisticated enough.

An advantage of pvm is that there is a large, well funded group working on
it.  It is possible that they will fix some of these problems, though
others are intrinsic in the design of the system.  One possibility is
to use a system that allows you to switch between p4, pvm, and others;
I've written such a system (which also handles the initial interface,
and the in the pvm case, handles propagating the environment to the
other workers in a parallel application).  Let me know if you would like
more information.
Bill Gropp

-----------------

From: "Christian P. Roberts" <[e-mail]>
To: Martin Beaudoin <[e-mail]>
Subject: Re: pvm vs p4
Date: Tue, 18 Aug 1992 17:46:57 -0400

In article <[e-mail]> you write:
|> I would like to know the pros ans cons of using pvm rather than p4
|> over a network of Suns.
|>

  I don't know about p4, but one thing to factor in is whether
you might ever want to run in a heterogeneous environment.  Maybe
you're networking Suns right now, but down the road ...  PVM
works well over different machines (provided you have the same
version installed on them).  The folks at Oak ridge are aware
of this problem and are going to try to resolve it in the future.

--

Chris Roberts                     Academic Computing Center
[e-mail]                University of Virginia
[phone]                    Charlottesville, Virginia 22903

----------------------

From: [e-mail] (Sudy Bharadwaj)
To: [e-mail]
Subject: pvm/p4.
Date: Wed, 19 Aug 92 08:16:03 EDT


 Hello,

 I read your posting regarding pvm and p4.  We have an environment called
Linda which allows an application to execute over a network of Suns.
The big difference between our and pvm/p4 is that we utilize a shared
memory model, while pvm/p4 utilize a distributed memory model.

 If you would like further information, please send me your full
mailing address, and I will be happy to send it to you.

Sudy Bharadwaj                                          Phone: [phone]
Director of Sales
Scientific Computing Associates, Inc.                   Fax:   [phone]
One Century Tower
265 Church Street
New Haven, CT 06510-7010                                email: [e-mail]

-----------------

From: [e-mail] (Angela Quealy)
To: [e-mail]
Subject: Re: pvm vs. p4
Date: Thu, 20 Aug 92 16:55:41 -0400


I've used both.  In fact, there are several similar packages out
there:  PVM, P4, TCGMSG, PICL and APPL.  I developed APPL at
NASA Lewis Research Center, based on the work done at Argonne
National Lab with P4 and TCGMSG.  Unfortunately because it was
developed at NASA, it is restricted to distribution within the
USA, so I can't send you a copy.

Both p4 and PVM will allow you to run an application across a network
of Suns.  What p4 gives you (and APPL as well), in addition to that,
is portability.  You can take that application which runs across the network,
and move it to an Intel hypercube, and it will run across the nodes of the
hypercube.  The applications written with p4 are portable, in fact,
to all of the platforms on which p4 has been implemented.

PVM is "portable" to the hypercube, but that means that
you can use the Intel as a "node" in the distributed environment.
PVM only talks to the host of the hypercube.  If you wanted your code
to run across the nodes of the hypercube, you'd have to replace your
PVM communication primitives with calls to Intel's message passing
library.  That may change in the future, but at the moment, that's where
the basic difference lies.

PVM is a very nice package for doing computations across a network of
heterogeneous machines.  It also seems to be widely used.  I was
able to code and run some simple examples in about an hour.
It took a little longer to get a P4 application running, but they've
made a lot of improvements since I've last used it.

Look into TCGMSG from Argonne as well.  It was developed by
Robert Harrison.

Angela Quealy
[e-mail]

***********************************************************************
*  Angela Quealy                        [e-mail]      *
*  Sverdrup Technology, Inc.            [phone]                *
*  NASA Lewis Research Center Group                                   *
***********************************************************************



----------------------

From: [e-mail] (David Levine)
To: [e-mail]
Subject: posting
Date: Mon, 24 Aug 92 09:57:09 CDT


> I would like to know the pros ans cons of using pvm rather than p4
> over a network of Suns.

I use p4 (it was developed down the hall), but have not used pvm.
Having spoke to users of both (and other similar systems) here are some
of the *major* differences I'm aware of:

* In addition to the message passing model, p4 supports the shared memory
model and an integrated combination of the two.

* p4 does direct process-to-process communication as opposed to passing
messages to daemons (==> efficient communication).

* p4 has an X-based graphical performance monitoring system called Upshot

* pvm has a front-end pkg called hence to graphically build a pvm program.
This is similar to the program build that had similar functionality with the
schedule pkg.

regards --dave

David Levine  [e-mail]  (708)-252-6735   Fax: [phone]
MCS 221 C-216    Argonne National Laboratory   Argonne, Illinois 60439

BTW, for what its worth, I use p4 on our Sun network for code development and
then just recompile/link to run on our Intel systems.

------------------

From: Rusty Lusk <[e-mail]>
To: [e-mail]
Subject: p4 vs. pvm
Date: Wed, 26 Aug 92 17:27:55 CDT


I am the author of p4, and can speak at least for the p4 side.

| I would like to know the pros ans cons of using pvm rather than p4
| over a network of Suns.
| After browsing the documentation of both packages, I am under the
| impression that they are both very similar.
|

For programming network of suns, they are indeed similar, being interfaces to
the socket and xdr libraries.

| Are there any noticable differences in the ease of programming or
| speed of execution between the two??
|

Some highly preliminary experiments here have shown p4 slightly faster, but not
significantly so.  Once you are communicating over sockets, system overhead
dominates almost anything.

| I am planning to use one the package for my work on computer vision, so I
| would like to receive any comments from anyone with some experience
| with one or both packages.
|

The big difference between the two packages is that p4 is a system for
portable programming of parallel machines in general, and networks of
workstations are just one of the platforms.  You can program shared-memory
machines with either the monitor or message-passing paradigms, and you can
program very fast parallel machines like the Intel Delta.  I routinely debug
programs on shared-memory systems where there is a good parallel debugging
environment, like a Sequent Symmetry or BBN TC-2000, and then do the
production runs on the Delta or IPSC860, without changing any source code.
A port to the CM-5 is in the works.

I include the current official blurb in case you don't already have it.  A new
release (version 1.1) is due out in a week or so.  Please let me know if you
have any questions or problems with the system.

Regards,
Rusty Lusk

                      p4


p4 is a library of macros and subroutines developed at Argonne National
Laboratory for programming a variety of parallel machines.  Its predecessor
was the m4-based "Argonne macros" system described in the Holt, Rinehart, and
Winston book "Portable Programs for Parallel Processors, by Lusk, Overbeek, et
al., from which p4 takes its name.  The current p4 system maintains the same
basic computational models described there (monitors for the shared-memory
model, message-passing for the distributed-memory model, and support for
combining the two models) while significantly increasing ease and flexibility
of use.

The current release is version 0.3.1.  New features added since version 0.2
include:

  + manual enhanced and converted to latex format
  + Emacs info version of the manual for on-line help
  + SYSV IPC support added for several machines (for shared-memory
     multiprocessing on workstations that support multiple processors)
  + instrumentation added for automatic logging/tracing
  + provided better user-control of message-passing/buffer-management
  + high-resolution clock support added for several machines
  + improved error/interrupt handling
  + optional secure server for faster startup on networks
  + optional automatic logging of events for upshot tracing

New since version 0.1:

  + xdr for communication in a heterogeneous network
  + asynchronous communication of large messages
  + global operations (broadcast, global sum, max, etc.)
  + both master-slave and SPMD models for message-passing programs
  + an improved and simplified Fortran interface
  + an optional secure server
  + ports to more machines

p4 is intended to be portable, simple to install and use, and efficient.  It
can be used to program networks of workstations, advanced parallel
supercomputers like the Intel Touchstone Delta and the Alliant Campus
HiPPI-based system, and single shared-memory multiprocessors.  It has
currently been installed on the following list of machines: Sequent Symmetry,
Encore Multimax, Alliant FX/8, FX/800, and FX/2800, Cray X/MP, Sun, NeXT, DEC,
Silicon Graphics, and IBM RS6000 workstations, Stardent Titan, BBN GP-1000 and
TC-2000, Intel IPSC/860, Intel Touchstone Delta, and Alliant Campus.  It will
soon be ported to the CM-5 and to the Intel Paragon.  It is not difficult to
port to new systems.

A useful companion system is the upshot logging and X-based trace examination
facility.  The macros to create logs are included in p4.  Upshot (an X program
for graphically displaying the logs) is available separately.

You can obtain the complete distribution of p4 by anonymous ftp from
info.mcs.anl.gov.  Take the file p4.tar.Z from the directory pub/p4.  The
distribution contains all source code, installation instructions, a User's
Guide in both ascii text and latexinfo format, and a collection of examples in
both C and Fortran.

To ask questions about p4, report bugs, contribute examples, etc., send mail
to [e-mail].

                                                   Rusty Lusk
                                                   [e-mail]
----------------

The end.




--
Martin Beaudoin                         [e-mail]
Institut de recherche d'Hydro-Quebec    [e-mail]
Varennes, QC, Canada   J3X 1S1          [phone]