[mpich2-dev] MPIX vs. MPI etc.

[Jeff Hammond]

Okay, but then why can't IBM implement MPIX_Ibarrier in such a way
that it returns an error every time?  Bill seemed to object to that,
which indicates that MPIX_Ibarrier must be implemented in a way that
complies with MPI-3 or not at all.  That is inconsistent with the
assertion that it's outside the standard.  I completely understand why
Bill wants what he wants; I am just trying to reconcile the
triple-meaning of MPIX that I observe.

I guess I don't see what's so wrong with IBM implementing
MPIX_Ibarrier just like it does the following, which all call
MPID_Abort.

anlvpn252:src jhammond$ grep "int MPID" misc/mpid_unimpl.c
int MPID_Close_port(const char *port_name)
int MPID_Open_port(MPID_Info *info_ptr,
int MPID_Comm_accept(char *port_name,
int MPID_Comm_connect(const char *port_name,
int MPID_Comm_disconnect(MPID_Comm *comm_ptr)
int MPID_Comm_spawn_multiple(int count

I don't really see any reason that these can't be implemented, by the
way, but IBM doesn't like them for obvious reasons.

Jeff

On Sun, Aug 19, 2012 at 10:42 PM, Pavan Balaji <balaji at mcs.anl.gov> wrote:
>
> MPIX_ functions were always meant to be extensions beyond the MPI standard.
> The fact that these functions might get into the standard in MPI-3 does not
> change that fact.  Apart from ARMCI-MPI, everything else follows this rule
> correctly.  ARMCI-MPI does not use MPIX_ names at all; it is just in the
> wrong directory.
>
>  -- Pavan
>
>
> On 08/19/2012 10:36 PM, Jeff Hammond wrote:
>>
>> I don't really care if we resolve this for all time tonight, I just
>> think it's worth noting that the current situation is confusing if one
>> tries to be logical about it.
>>
>> Jeff
>>
>>
>> ---------- Forwarded message ----------
>> From: Jeff Hammond <jhammond at alcf.anl.gov>
>> Date: Sun, Aug 19, 2012 at 10:33 PM
>> Subject: Re: [mpich-ibm] pamid code contribution - based on mpich2 1.5b2
>> To: Pavan Balaji <balaji at mcs.anl.gov>
>> Cc: William Gropp <wgropp at illinois.edu>, mpich-ibm at mcs.anl.gov
>>
>>
>> I agree that a user will be annoyed if an MPIX_Ibarrier symbol exists
>> in MPICH2-1.5's PAMID but it doesn't work, however...
>>
>> This refers to the MPIX implementations of MPI-3 that are not yet
>> standardized, does it not?  Is MPICH2-1.5 going to be an
>> implementation of MPI-2.2 or MPI-3?  If the former, what is the
>> argument for not letting the PAMID implementation of MPICH2-1.5 catch
>> on fire and burn down the machine room when users call MPIX_Ibarrier?
>> They have no reasonable expectation that this should work.  Only
>> informed experts should be calling MPIX anyways, no?
>>
>> This further confirms that the MPIX situation is confusing.  MPICH2
>> has MPIX for MPI-3 that are portable except for BGQ, MPIX that have no
>> meaning except on BGQ, and MPIX that aren't in the standard but work
>> everywhere because they sit on top of MPI.  It also strengthens my
>> argument that there's no sense in trying to make MPIX user-friendly
>> since these details are not something a novice can distinguish.
>>
>> The best solution is for IBM to implement all the MPIX functions in
>> MPICH2-1.5, of course, starting with NBC and RMA :-)
>>
>> Jeff
>>
>> On Sun, Aug 19, 2012 at 10:26 PM, Pavan Balaji <balaji at mcs.anl.gov> wrote:
>>>
>>>
>>> Agreed.  I like Bill's suggestion better.
>>>
>>>   -- Pavan
>>>
>>>
>>> On 08/19/2012 10:24 PM, William Gropp wrote:
>>>>
>>>>
>>>> I have a different concern about this (not about the IBM patch but the
>>>> underlying approach).  I think it is a mistake to include unimplemented
>>>> routines at all in the library.   In particular, there is no easy way to
>>>> write a configure test for this without running the code; the model that
>>>> configure uses for checking for a the availability of a function is
>>>> whether a program containing it can be linked.  Applications should be
>>>> encouraged to use standard tools for determining capabilities.
>>>>    Including non-functional stubs breaks this model, and does so
>>>> unnecessarily.
>>>>
>>>> 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 Aug 20, 2012, at 9:43 AM, Pavan Balaji wrote:
>>>>
>>>>> 5. Patch #3: For the MPI-3 functionality that's not implemented, it
>>>>> looks like you are just calling an Abort.  I'd recommend adding a new
>>>>> error code MPIX_ERR_NOT_IMPLEMENTED and return that instead.  That
>>>>> way, applications might be able to do something useful with those
>>>>> functions.
>>>>
>>>>
>>>>
>>>
>>> --
>>> Pavan Balaji
>>> http://www.mcs.anl.gov/~balaji
>>> _______________________________________________
>>> mpich-ibm mailing list
>>> mpich-ibm at lists.mcs.anl.gov
>>> https://lists.mcs.anl.gov/mailman/listinfo/mpich-ibm
>>
>>
>>
>>
>> --
>> Jeff Hammond
>> Argonne Leadership Computing Facility
>> University of Chicago Computation Institute
>> jhammond at alcf.anl.gov / (630) 252-5381
>> http://www.linkedin.com/in/jeffhammond
>> https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond
>>
>>
>
> --
> Pavan Balaji
> http://www.mcs.anl.gov/~balaji



-- 
Jeff Hammond
Argonne Leadership Computing Facility
University of Chicago Computation Institute
jhammond at alcf.anl.gov / (630) 252-5381
http://www.linkedin.com/in/jeffhammond
https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond