On 10 February 2010 09:31, Jeff Squyres <jsquy...@cisco.com> wrote:
> Thanks for the reminder.
>
> Note that from a standards perspective, note that MPI_REDUCE *does* require 
> at least one element -- MPI-2.2 p163:34-35:
>
>   "Each process can provide one element, or a sequence of elements..."
>

Are you really convinced that such sentence means that zero elements
is illegal? I have the feeling that this corner case was not taken
into account at the time that wording was written (wich dates back to
MPI 1.1 standard).

Is there a rationale for requiring at least one element? Is this worth
a change/clarification in the MPI standard?

>
> So I think that George's assertion is correct: your test code is incorrect.
>

Well, you have to grant me that a zero-length reduction seems
something plausible to test. I still think OMPI is following too
strictly the wording "Each process can provide one element". Again,
this sentence comes from MPI-1.1 .

Please, do not take me wrong. If there is an actual issue with
zero-length reductions, I want to know about it. Otherwise, I would
like to ask you to revisit OMPI behavior. I'm still thinking that
there is no good reason for zero-length reductions to invalid
operations, they should be just non-op calls.

> But that's not what is causing your example to fail.  Here's the issue in 
> OMPI's MPI_Reduce:
>
>        } else if ((ompi_comm_rank(comm) != root && MPI_IN_PLACE == sendbuf) ||
>                   (ompi_comm_rank(comm) == root && ((MPI_IN_PLACE == recvbuf) 
> || (sendbuf == recvbuf)))) {
>            err = MPI_ERR_ARG;
>
> The "sendbuf == recvbuf" check is what causes the MPI exception.  I would say 
> that we're not consistent about disallowing that (e.g., such checks are not 
> in MPI_SCAN and the others you cited).
>

Yes, I understand that. But in the case that zero-length reductions
were valid, the check should not fall-back there...

> But FWIW, we do have logic in there because a popular benchmark (IMB) gets it 
> wrong and calls MPI_REDUCE with a zero count (or at least, it used to -- I 
> don't know if it has been checked).  This is a case where we were backed into 
> a corner because users kept complaining that OMPI was broken because it would 
> fail to run IMB (although the opposite was actually true).  So even though we 
> didn't want to add the exception, we pretty much had to.  :-\
>

I see. I understand that IMB is not the MPI standard, but again,
zero-length reductions is a good candidate for test writers, because
these folks love corner cases :-)


> Hence, we're not failing your example because of a 0 count -- we're failing 
> your example because you didn't use MPI_IN_PLACE.  The following works 
> (because of the IMB exception), for example:
>
>  ierr = MPI_Reduce(
>                    (void*) 1, (void*) 2,
>                    0,
>                    MPI_INT,
>                    MPI_SUM,
>                    0,
>                    MPI_COMM_WORLD);
>
>

But NULL is a very special case. Using (ptr=NULL,len=0) for
zero-length arrays is common out there.

In short, I still think that (sendbuf=NULL,recvbuf=NULL,count=0)
should work. Not sure about
(sendbuf=(void*)1,recvbuf=(void*)1,count=0) , but I can imagine cases
were this would be nice to have (e.g. some dynamic language, or
library, or even user code that employs a singleton for zero-length
arrays)

Special casing Open MPI in my testsuite to disable these tests is just
a matter of adding two lines,  but before that I would like to have
some sort of final pronouncement on all this from your side.


-- 
Lisandro Dalcín
---------------
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

Reply via email to