Newsgroups: comp.parallel.pvm
From: eve_li@btgmax.zko.dec.com (Eve Li)
Subject: Re: pvm message passing timing
Organization: Digital Equipment Corporation
Date: 11 Aug 1995 04:21:00 GMT
Message-ID: <40elrc$jh7@nntpd.lkg.dec.com>

Erik Demaine (edemaine@ug.cs.dal.ca) wrote:
: clock (user and system time) does *not* include the extra time to wait
: for a message to be received in typical message-passing (e.g., PVM), because
: the method used is blocking (which takes wall-clock time, but no CPU time)
: and not polling.  Thus, gettimeofday (or equivalent) _must_ be used to take

Is this really true? Does PVM really using blocking message-passing? 
How about pvm-psend, pvm-precv? 
The documentation says:
	The pvm_psend routine is asynchronous.  Computation on the
       sending processor resumes as soon as the  buffer  is  safe
       for  reuse.  This is in contrast to synchronous communica-
       tion, during which computation on  the  sending  processor
       halts  until  the  matching  receive  is  executed  by the
       receiving processor.


My guess is that gettimeofday is still better when pvm-psend/pvm-precv
are used because pvm_psend could block if there are too much data to send
or recv. Thus, it takes more wall clock time than cpu time. 

any comments? 
 
eve
: into account message-passing time, unless it is guaranteed that the message
: is already available.  Unfortunately, this doesn't work well when other
: jobs are running simulaneously.  As far as I know, there is no great way
: to time a parallel program under these circumstances.

