[mpich2-dev] fandcattrf90 test on BGP

[Brian Smith]

This test actually came directly from the MPI2.2 updates. :)

And I full agree that attributes are too complicated, and it's even worse 
when mixing fortran and C.

Joe's proposal fixes things in MPICH, but I don't know if you want to 
implement it or not. It also cleans up some MPICH code too.


Brian Smith
BlueGene MPI Development
IBM Rochester
Phone: 507 253 4717
smithbr at us.ibm.com




"Rajeev Thakur" <thakur at mcs.anl.gov> 
Sent by: mpich2-dev-bounces at mcs.anl.gov
07/24/2009 05:27 PM
Please respond to
mpich2-dev at mcs.anl.gov


To
<mpich2-dev at mcs.anl.gov>
cc

Subject
Re: [mpich2-dev] fandcattrf90 test on BGP






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_attr.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/fandcattrf90.f90

https://svn.mcs.anl.gov/repos/mpi/mpich2/trunk/test/mpi/f90/attr/fandcattrc.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/41d5ba89/attachment.htm>