Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] failure with zero-lengthReduce()andbothsbuf=rbuf=NULL
From: Jeff Squyres (jsquyres) (jsquyres_at_[hidden])
Date: 2010-02-11 07:04:59


Where does bcast(1) synchronize?

(Oops on typo - if reduce(1) wasn't defined, that definitely would be bad :) )

-jms
Sent from my PDA. No type good.

----- Original Message -----
From: devel-bounces_at_[hidden] <devel-bounces_at_[hidden]>
To: Open MPI Developers <devel_at_[hidden]>
Sent: Wed Feb 10 12:50:03 2010
Subject: Re: [OMPI devel] failure with zero-lengthReduce()andbothsbuf=rbuf=NULL

On 10 February 2010 14:19, Jeff Squyres <jsquyres_at_[hidden]> wrote:
> On Feb 10, 2010, at 11:59 AM, Lisandro Dalcin wrote:
>
>> > If I remember correctly, the HPCC pingpong test synchronizes occasionally by
>> > having one process send a zero-byte broadcast to all other processes.
>> >  What's a zero-byte broadcast?  Well, some MPIs apparently send no data, but
>> > do have synchronization semantics.  (No non-root process can exit before the
>> > root process has entered.)  Other MPIs treat the zero-byte broadcasts as
>> > no-ops;  there is no synchronization and then timing results from the HPCC
>> > pingpong test are very misleading.  So far as I can tell, the MPI standard
>> > doesn't address which behavior is correct.
>>
>> Yep... for p2p communication things are more clear (and behavior more
>> consistens in the MPI's out there) regarding zero-length messages...
>> IMHO, collectives should be non-op only in the sense that no actual
>> reduction is made because there are no elements to operate on. I mean,
>> if Reduce(count=1) implies a sync, Reduce(count=0) should also imply a
>> sync...
>
> Sorry to disagree again.  :-)
>
> The *only* MPI collective operation that guarantees a synchronization is barrier.  The lack of synchronization guarantee for all other collective operations is very explicit in the MPI spec.

Of course.

> Hence, it is perfectly valid for an MPI implementation to do something like a no-op when no data transfer actually needs to take place
>

So you say that an MPI implementation is free to do make a sync in
case of Bcast(count=1), but not in the case of Bcast(count=0) ? I
could agree that such behavior is technically correct regarding the
MPI standard... But it makes me feel a bit uncomfortable... OK, in the
end, the change on semantic depending on message sizes is comparable
to the blocking/nonblocking one for MPI_Send(count=10^8) versus
Send(count=1).

>
> (except, of course, the fact that Reduce(count=1) isn't defined ;-) ).
>

You likely meant Reduce(count=0) ... Good catch ;-)


PS: The following question is unrelated to this thread, but my
curiosity+laziness cannot resist... Does Open MPI has some MCA
parameter to add a synchronization at every collective call?

--
Lisandro Dalcin
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594

_______________________________________________
devel mailing list
devel_at_[hidden]
http://www.open-mpi.org/mailman/listinfo.cgi/devel