December 2012 - devel - mailman3.cels.anl.gov

Re: [mpich-devel] datatype accessors with uncommited datatypes
by Pavan Balaji 27 Dec '12

27 Dec '12

On 12/27/2012 02:05 PM US Central Time, William Gropp wrote: > The standard is already clear - commit is only required when the > datatype is used for communication. It is unnecessary for the > standard to list all cases where commit is not required - it is > enough to list where commit *is* required, which it does. The way the text is currently written, it says "it is required for case X and not required for case Y" instead of saying "not required for all other cases". If the intended behavior is to not throw an error for non-communication routines, then the one example (of datatype constructors) should be removed from the standard, or just rewritten as "other operations such as datatype constructors". If that was the intention of the MPI-1 authors (you are one of them, so I'll take your word for it), we obviously don't have to wait till the standard fixes this to fix it in MPICH. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-devel] datatype accessors with uncommited datatypes
by William Gropp 27 Dec '12

27 Dec '12

The standard is already clear - commit is only required when the datatype is used for communication. It is unnecessary for the standard to list all cases where commit is not required - it is enough to list where commit *is* required, which it does. From a practical standpoint, the purpose of commit is to give the MPI implementation the opportunity to build specialized datatype pack/unpack code at runtime. This is irrelevant for the accessor functions. For example, the size of the datatype is independent of any optimizations for data communication, which is what the commit step is for. This is a clear error in MPICH; it is unnecessary to bother the Forum with this. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Dec 27, 2012, at 1:08 PM, Lisandro Dalcin wrote: > On 27 December 2012 16:01, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: >> >> On 12/27/2012 12:56 PM US Central Time, Jeff Hammond wrote: >>> I don't disagree with your interpretation, but I am always hesitant to >>> assert my understanding of the text in the absence of input from those >>> who were present when it was written. >>> >>> I'll file an MPI Forum ticket and see what happens. >> >> This does look like something that's ill-defined in the standard. A >> ticket to address in MPI-3.1 is a good idea. >> >> Lisandro: till this is fixed in the standard, the workaround will be to >> commit all datatypes. >> > > So, in MPICH 3.x, given an uncommited datatype, MPI_Type_size() will > succeed, but MPI_Type_size_x() will fail ? > > -- > Lisandro Dalcin > --------------- > CIMEC (INTEC/CONICET-UNL) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1011) > Tel/Fax: +54-342-4511169

1 0

Re: [mpich-devel] datatype accessors with uncommited datatypes
by Lisandro Dalcin 27 Dec '12

27 Dec '12

On 27 December 2012 16:01, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > On 12/27/2012 12:56 PM US Central Time, Jeff Hammond wrote: >> I don't disagree with your interpretation, but I am always hesitant to >> assert my understanding of the text in the absence of input from those >> who were present when it was written. >> >> I'll file an MPI Forum ticket and see what happens. > > This does look like something that's ill-defined in the standard. A > ticket to address in MPI-3.1 is a good idea. > > Lisandro: till this is fixed in the standard, the workaround will be to > commit all datatypes. > So, in MPICH 3.x, given an uncommited datatype, MPI_Type_size() will succeed, but MPI_Type_size_x() will fail ? -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [mpich-devel] datatype accessors with uncommited datatypes
by Jeff Hammond 27 Dec '12

27 Dec '12

On Thu, Dec 27, 2012 at 1:01 PM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > On 12/27/2012 12:56 PM US Central Time, Jeff Hammond wrote: >> I don't disagree with your interpretation, but I am always hesitant to >> assert my understanding of the text in the absence of input from those >> who were present when it was written. >> >> I'll file an MPI Forum ticket and see what happens. > > This does look like something that's ill-defined in the standard. A > ticket to address in MPI-3.1 is a good idea. > > Lisandro: till this is fixed in the standard, the workaround will be to > commit all datatypes. See https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/356. Jeff -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-devel] datatype accessors with uncommited datatypes
by Pavan Balaji 27 Dec '12

27 Dec '12

On 12/27/2012 12:56 PM US Central Time, Jeff Hammond wrote: > I don't disagree with your interpretation, but I am always hesitant to > assert my understanding of the text in the absence of input from those > who were present when it was written. > > I'll file an MPI Forum ticket and see what happens. This does look like something that's ill-defined in the standard. A ticket to address in MPI-3.1 is a good idea. Lisandro: till this is fixed in the standard, the workaround will be to commit all datatypes. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-devel] datatype accessors with uncommited datatypes
by Jeff Hammond 27 Dec '12

27 Dec '12

I don't disagree with your interpretation, but I am always hesitant to assert my understanding of the text in the absence of input from those who were present when it was written. I'll file an MPI Forum ticket and see what happens. Jeff On Thu, Dec 27, 2012 at 12:48 PM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > On 27 December 2012 15:36, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: >> This is what the MPI standard says: >> >> 4.1.9 Commit and Free >> A datatype object has to be committed before it can be used in a >> communication. As an argument in datatype constructors, uncommitted >> and also committed datatypes can be used. There is no need to commit >> basic datatypes. They are “pre-committed.” >> >> There is some ambiguity since the functions to which you refer lie >> outside of the union of "communication" and "datatype constructors". >> However, since MPI_TYPE_SIZE(_X) determine "the total size of the data >> in a message that would be created with this datatype", I wonder if >> there is an implementation wherein the "compilation" that can >> potentially occur during MPI_TYPE_COMMIT is required in order to >> satisfy MPI_TYPE_SIZE(_X). >> > > I would argue that a "datatype constructor" is a much more complex > operation that a "datatype accessor", so if construction should work > with uncommited, I would expect accessors to work, too. Moreover, the > current implementation of MPI_Type_size() seems to agree with my POV. > >> Is it necessary for mpi4py to have the behavior of the older version >> of MPICH to function properly or can you work around this for now? >> > > It is not a problem of mpi4py, actually, buy user's code out there > that could potentially break (BTW, this issue also applies to C and > Fortran codes). > > > -- > Lisandro Dalcin > --------------- > CIMEC (INTEC/CONICET-UNL) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1011) > Tel/Fax: +54-342-4511169 -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-devel] datatype accessors with uncommited datatypes
by Lisandro Dalcin 27 Dec '12

27 Dec '12

On 27 December 2012 15:36, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > This is what the MPI standard says: > > 4.1.9 Commit and Free > A datatype object has to be committed before it can be used in a > communication. As an argument in datatype constructors, uncommitted > and also committed datatypes can be used. There is no need to commit > basic datatypes. They are “pre-committed.” > > There is some ambiguity since the functions to which you refer lie > outside of the union of "communication" and "datatype constructors". > However, since MPI_TYPE_SIZE(_X) determine "the total size of the data > in a message that would be created with this datatype", I wonder if > there is an implementation wherein the "compilation" that can > potentially occur during MPI_TYPE_COMMIT is required in order to > satisfy MPI_TYPE_SIZE(_X). > I would argue that a "datatype constructor" is a much more complex operation that a "datatype accessor", so if construction should work with uncommited, I would expect accessors to work, too. Moreover, the current implementation of MPI_Type_size() seems to agree with my POV. > Is it necessary for mpi4py to have the behavior of the older version > of MPICH to function properly or can you work around this for now? > It is not a problem of mpi4py, actually, buy user's code out there that could potentially break (BTW, this issue also applies to C and Fortran codes). -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [mpich-devel] datatype accessors with uncommited datatypes
by Jeff Hammond 27 Dec '12

27 Dec '12

This is what the MPI standard says: 4.1.9 Commit and Free A datatype object has to be committed before it can be used in a communication. As an argument in datatype constructors, uncommitted and also committed datatypes can be used. There is no need to commit basic datatypes. They are “pre-committed.” There is some ambiguity since the functions to which you refer lie outside of the union of "communication" and "datatype constructors". However, since MPI_TYPE_SIZE(_X) determine "the total size of the data in a message that would be created with this datatype", I wonder if there is an implementation wherein the "compilation" that can potentially occur during MPI_TYPE_COMMIT is required in order to satisfy MPI_TYPE_SIZE(_X). Is it necessary for mpi4py to have the behavior of the older version of MPICH to function properly or can you work around this for now? Best, Jeff On Thu, Dec 27, 2012 at 10:50 AM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > My understanding of the MPI standard is that datatype committing is > only required for communication, but not for calls like > MPI_Type_size_x(). I'm testing mpi4py with mpich-3.0.1, and getting > the following errors (IIRC, 3.0rc1 did not have this issue) > > mpi4py.MPI.Exception: Invalid datatype, error stack: > PMPI_Type_size_x(125): MPI_Type_size_x(datatype=dtype=USER<vector>, > size=0x7fffeb4ef658) > PMPI_Type_size_x(98).: Datatype has not been committed > > > mpi4py.MPI.Exception: Invalid datatype, error stack: > PMPI_Type_get_extent_x(128): > MPI_Type_get_extent_x(datatype=dtype=USER<struct>, lb=0x7fff97046bb0, > extent=0x7fff97046bb8) > PMPI_Type_get_extent_x(102): Datatype has not been committed > > Looking more closely to type_size_x.c and type_size.c in > src/mpi/datatype/, I see MPID_Datatype_committed_ptr() in the former, > but not in the later. IMHO, these checks should be removed from > type_size_x.c, type_get_extent_x.c, and type_get_true_extent_x.c > (please not I'm not listing get_elements_x.c, this is a different > beast) > > Thanks, > > -- > Lisandro Dalcin > --------------- > CIMEC (INTEC/CONICET-UNL) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1011) > Tel/Fax: +54-342-4511169 -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

datatype accessors with uncommited datatypes
by Lisandro Dalcin 27 Dec '12

27 Dec '12

My understanding of the MPI standard is that datatype committing is only required for communication, but not for calls like MPI_Type_size_x(). I'm testing mpi4py with mpich-3.0.1, and getting the following errors (IIRC, 3.0rc1 did not have this issue) mpi4py.MPI.Exception: Invalid datatype, error stack: PMPI_Type_size_x(125): MPI_Type_size_x(datatype=dtype=USER<vector>, size=0x7fffeb4ef658) PMPI_Type_size_x(98).: Datatype has not been committed mpi4py.MPI.Exception: Invalid datatype, error stack: PMPI_Type_get_extent_x(128): MPI_Type_get_extent_x(datatype=dtype=USER<struct>, lb=0x7fff97046bb0, extent=0x7fff97046bb8) PMPI_Type_get_extent_x(102): Datatype has not been committed Looking more closely to type_size_x.c and type_size.c in src/mpi/datatype/, I see MPID_Datatype_committed_ptr() in the former, but not in the later. IMHO, these checks should be removed from type_size_x.c, type_get_extent_x.c, and type_get_true_extent_x.c (please not I'm not listing get_elements_x.c, this is a different beast) Thanks, -- Lisandro Dalcin --------------- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

1 0

Re: [mpich-devel] LLONG_MAX undeclared in status_set_elements_x.c ?
by William Gropp 21 Dec '12

21 Dec '12

Thanks. This test erroneously uses long long and LLONG_MAX without ensuring that they are available (and for which the configure for the tests already checks). I'll fix it. Bill William Gropp Director, Parallel Computing Institute Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign On Dec 21, 2012, at 2:25 AM, P.-H. Lin wrote: > Hello Howard, > I have encountered the same problem with mpich-3.0.1 today. (And > that's why I found this thread :P) > After raising the optimization level, it didn't complain about that > undeclared problem anymore, and the installation goes well. > This is my configure option: > ./configure --prefix /opt/app/MPICH --enable-fast=all,O3 > > BTW, the problem still exist for "indexed-misc.c" under the test directory > > Regards

1 0