[mpich2-dev] fandcattrf90 test on BGP

[Rajeev Thakur]

This attribute stuff in MPI is too complicated. One should check that
any change does not violate any of the cases outlined in the clarifying
examples being added to MPI 2.2. See ticket 55:
https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/55
 
Rajeev
 


  _____  

From: mpich2-dev-bounces at mcs.anl.gov
[mailto:mpich2-dev-bounces at mcs.anl.gov] On Behalf Of Joe Ratterman
Sent: Tuesday, July 21, 2009 9:59 AM
To: mpich2-dev at mcs.anl.gov
Subject: Re: [mpich2-dev] fandcattrf90 test on BGP


I think I agree that the the third would be a Fint, but I don't
understand this stuff either.  There are three types of attributes. 
MPIR_ATTR_AINT
MPIR_ATTR_PTR
MPIR_ATTR_INT
An attribute created in C is a PTR, in Fortran it is an AINT, and the
depricated put/get interface in Fortran sets the type to INT.  I thought
it was in put/get for C, but I don't see it now.

https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk/src/mpi/attr/comm_get_att
r.c
MPI_Comm_get_attr has a small pile of code to select the correct version
and handle it correctly:

   if (p->keyval->handle == comm_keyval) {
*flag                  = 1;
if (outAttrType == MPIR_ATTR_PTR) {
   if (p->attrType == MPIR_ATTR_INT) {
/* This is the tricky case: if the system is
bigendian, and we have to return a pointer to
an int, then we may need to point to the 
correct location in the word. */
#if defined(WORDS_LITTLEENDIAN) || (SIZEOF_VOID_P == SIZEOF_INT)
*(void**)attribute_val = &(p->value);
#else
int *p_loc = (int *)&(p->value);
#if SIZEOF_VOID_P == 2 * SIZEOF_INT
p_loc++;
#else 
#error Expected sizeof(void*) to be either sizeof(int) or 2*sizeof(int)
#endif
*(void **)attribute_val = p_loc;
#endif
   }
   else if (p->attrType == MPIR_ATTR_AINT) {
*(void**)attribute_val = &(p->value);
   }
   else {
*(void**)attribute_val = (p->value);
   }
}
else
   *(void**)attribute_val = (p->value);

break;
   }

The part that handles a larger void* than int, and especially the
endian-ness part, would be easier with a union.  Since the Aint and the
void* are different on our system, it would help that too.


Joe Ratterman
jratt at us.ibm.com


On Mon, Jul 20, 2009 at 5:37 PM, Dave Goodell <goodell at mcs.anl.gov>
wrote:


On Jul 16, 2009, at 4:55 PM, Joe Ratterman wrote:



(This is a re-send; I got a pile of python errors on the last try)



Sorry about that.  The IT department here upgraded both Trac and SVN
last week and it didn't go as smoothly as it could have.  Those problems
should all be resolved at this point. 



https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk/test/mpi/f90/attr/fandcat
trf90.f90
https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk/test/mpi/f90/attr/fandcat
trc.c

This test creates an attribute in F90, sets it in F90, and then reads it
back in C.  It was getting the wrong answer:
Expected:           5555 (0x15b3)
Actual:   23858543329280 (0x15b300000000)


... 


One idea that strikes me as really good is to change the "value" field
in the MPID_Attribute structure to be a union of int, void*, and
MPI_Aint types with three different names.  That would get rid of the
interesting work that is required to handle 8-byte void* and 4-byte
ints.  It would also make it easier to add MPI_Aint changes.  You
wouldn't have to worry about the strangeness of storing an integer type
in a pointer type, and it would automatically handle any differences in
the sizes of the elements.  You already track the data type, so you
would know into which element the attribute should be stored.

Comments or questions?



Sorry for the delayed response, I was hoping that someone else who knows
and likes attributes better than I do would jump in here.
Unfortunately, that doesn't seem to be happening, so I'll take a stab at
this.

Do you really mean that the value union should be this?
--------8<---------
union {
 MPI_Fint  f_int; /* instead of int */
 void     *void_p;
 MPI_Aint  a_int;
} value;
--------8<---------

This seems reasonable to me on its face, but I would feel better if
someone who was more active in MPI Forum ticket #55 [1] thought so too
(Rajeev?).  This is a really complicated section of the standard that
always confuses me on at least one or two issues every time I look at
it.

-Dave

[1] https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/55




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/mpich2-dev/attachments/20090724/241234c1/attachment.htm>