Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] failure with zero-length Reduce() and bothsbuf=rbuf=NULL
From: Lisandro Dalcín (dalcinl_at_[hidden])
Date: 2010-02-10 08:40:57


On 10 February 2010 09:31, Jeff Squyres <jsquyres_at_[hidden]> 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