January 2012 - Mpich2-core - mailman3.cels.anl.gov

Re: [mpich2-core] [mpich2-maint] MPIU_Handle_common casting to MPID_Datatype
by Darius Buntinas 11 Jan '12

11 Jan '12

It looks to me that the next field should be moved into the MPIU_OBJECT_HEADER macro. Does anyone (with fresher knowledge on object allocation than me) know if this isn't a good idea, or why it wasn't done? Thanks, -d On Jan 3, 2012, at 8:28 PM, Haizhu Liu wrote: > In file mpich2/src/mpi/datatype/typeutil.c function MPIR_Datatype_init(), the code calls > > ptr = (MPID_Datatype *)MPIU_Handle_obj_alloc_unsafe( &MPID_Datatype_mem ); > > Function MPIU_Handle_obj_alloc_unsafe returns the address of data of type MPIU_Handle_common. The casting has problem, because later it interprets the second element "void *" in MPIU_Handle_common as the second element "int size" in MPID_Datatype, which is what I saw with mpich test bucket io/rdwrord test case where it tries to call PAMI_Memregion_create() on a huge size of buffer. > > typedef struct MPIU_Handle_common { > MPIU_OBJECT_HEADER; > void *next; /* Free handles use this field to point to the next > free object */ > } MPIU_Handle_common; > > typedef struct MPID_Datatype { > /* handle and ref_count are filled in by MPIU_Handle_obj_alloc() */ > MPIU_OBJECT_HEADER; /* adds handle and ref_count fields */ > > /* basic parameters for datatype, accessible via MPI calls */ > int size; /* adding void *next before this element fixes the problem */ > MPI_Aint extent, ub, lb, true_ub, true_lb; > > /* chars affecting subsequent datatype processing and creation */ > int alignsize, has_sticky_ub, has_sticky_lb; > int is_permanent; /* non-zero if datatype is a predefined type */ > int is_committed; > > ... > } > > Adding void *next as the second element in MPID_Datatype() fixed the problem. Is the fix okay? > > Thanks, > Haizhu > > Communication Protocols > Advance Clustering Technology Team (ACTT) > IBM System and Technology Group > Poughkeepsie, NY 12601 > Phone : (845)-433-5857 (T/L: 293)_______________________________________________ > mpich2-maint mailing list > mpich2-maint(a)lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/mpich2-maint

4 5

Fwd: D
by Rajeev Thakur 08 Jan '12

08 Jan '12

We should look into what a D binding for MPI would look like (unofficial binding for now). Rajeev Begin forwarded message: > From: Rick Stevens <stevens(a)anl.gov> > Date: January 7, 2012 1:01:34 PM CST > To: Rusty Lusk <lusk(a)mcs.anl.gov> > Cc: Pavan Balaji <balaji(a)mcs.anl.gov>, thakur(a)mcs.anl.gov > Subject: Re: D > > http://www.d-programming-language.org/ > > invented initially by Walter Bright and with lots of work from Andrei Alexandrescu > > I highly recommend reading > > http://www.amazon.com/D-Programming-Language-Andrei-Alexandrescu/dp/0321635… > > well writing and the language is an improvement on C and C++ > > I'm writing code (small things for far) but I'm very impressed. Its very close to C but fixes many things > and is much safer and is cleaner than C++. Feels very good writing code in it. > > On Jan 7, 2012, at 12:56 PM, Rusty Lusk wrote: > >> Where does it come from? >> >> On Saturday,Jan 7, 2012, at 12:55 PM, Rick Stevens wrote: >> >>> Pavan, Rajeev, Rusty >>> >>> I'm becoming a big fan of the language D. I'm starting to be convinced that we should think about >>> a MPI binding for it. As far as I can tell that has not yet been done. Is there any interest in MCS >>> in doing this and any idea what the order of magnitude of effort is? >>> >>> --rick >> >

1 0

Fwd: meeting Plan for ANL visit
by Darius Buntinas 06 Jan '12

06 Jan '12

I'm including the rest of the group on this too. If anyone else has comments or anything to add, please feel free. Otherwise, this sounds fine. I'll arrange a gate pass for you. See you then. -d Begin forwarded message: > From: Vivek <vivek112(a)gmail.com> > Date: January 6, 2012 1:29:45 PM CST > To: Darius Buntinas <buntinas(a)mcs.anl.gov> > Cc: William Gropp <wgropp(a)illinois.edu> > Subject: meeting Plan for ANL visit > > Dear Darius, > > I made a rough meeting plan that I had discussed with Prof Gropp. > I will elaborate on this. Feel free to add on if you need. > Also, I think I needed a Gate Pass. I will look into this, and check how to do this . > I'm thinking try to aim for arrival at around 10AM, and spend time til 3PM. > I wasn't sure how long I should come for, but it would be great to talk for however > long is most convenient for you (and others). > > 1. Discuss MPI shared memory function implementation that we have. Focus on Darius's implementation (can briefly go through my functions if there is anything else needed from it). > > 2. Discuss actions items to get the shared memory functions into mpich2, and discuss how we can work together to get the functions added into mpich2. > > 3. Discuss different tests, and how each one would excercise different aspects of the shared memory functions: > a. tests that go over correctness of mpich2 functions > b. tests that go over performance , to be included as part of a EuroMPI paper. > c. application tests (NAS LU, NAS CG) > > > 4. Talk about timeline for longer-term collaboration possibly for EuroMPI paper. Items 3b,3c, may be relevant for this.

1 0

nightly tests
by Rajeev Thakur 05 Jan '12

05 Jan '12

Some nightly tests are not getting built or hanging. http://www.mcs.anl.gov/research/projects/mpich2/nightly/old/ Rajeev

1 0

Re: [mpich2-core] Visiting ANL
by Rajeev Thakur 05 Jan '12

05 Jan '12

Vivek, For me, the last week of January would the best. But you don't need me as such. You can come as long as others are there. I am CCing others to see if the Thu or Fri of the MPI Forum week works for them. Friday might. Rajeev On Dec 30, 2011, at 2:28 PM, Vivek Kale wrote: > Dear Dr. Thakur, > > We spoke about visiting ANL at the INRIA jointlab workshop(nov 21-23). I am wondering if sometime first week of jan or second week of jan would work. It looks like second week of Jan might work, though of course it would have to be something like Thursday or Friday since there is the MPI forum on the mon- wed of that week, and it is in California, as you mentioned. The main thing I wanted to visit for is mpich2 shared memory extensions, and hopefully have a face to face meeting with Darius Buntinas about implementation of some of the functions within Mpich2( along with some tests I have for these functions). > > -Vivek

5 5

Fwd: mpi_thread_funneled
by Rusty Lusk 04 Jan '12

04 Jan '12

Any clues? Begin forwarded message: > From: "Steven C. Pieper" <spieper(a)anl.gov> > Date: January 4, 2012 5:16:35 PM CST > To: Rusty Lusk <lusk(a)mcs.anl.gov>, Pavan Balaji <balaji(a)mcs.anl.gov> > Cc: Robert Wiringa <wiringa(a)phy.anl.gov> > Subject: mpi_thread_funneled > Reply-To: spieper(a)anl.gov > > Bob Wiringa is starting to use both MPI and OpenMP. > > His code does MPI calls only from the main program. The > openMP stuff is all in computational subroutines that > have no MPI stuff. > > Therefore I told him to call mpi_init_thread with mpi_thread_funneled. > But he was getting no OpenMP speedup at all -- even though > OpenMP reported that two threads were available (that is > what we specified with OMP_NUM_THREADS), the timing corresponded > exactly to 1 thread. The mpi_init_thread call did report back > that we got funneled. We then switched to mpi_thread_multiple > and it sped up by the expected factor of almost 2. > > This is on fusion with mvapich2/1.6.0-intel-11.1 . > > Shouldn't funneled have been good enough? Is this another > bug in 1.6 (we are still waiting for 1.7)? > > Steve > -- > Steven C. Pieper: spieper(a)anl.gov > Argonne National Laboratory, Physics Division, Bldg. 203, Argonne, IL 60439 > Phone: 630-252-4232 Fax -6008 > Secretary, Debra Morrison, -4100

2 1

build failure
by Rajeev Thakur 03 Jan '12

03 Jan '12

The nightly tests were building on Dec 21, but are failing since Dec 22. So some check-in on Dec 22 is the culprit. Rajeev

4 3