[mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF not profiled

Jeff Squyres (jsquyres) jsquyres at cisco.com
Mon May 19 10:35:08 CDT 2014


I think we need to push this errata out to the Japan meeting.  There seems to be a bunch of subtlety here; trying to rush this through today does not seem like a good idea just to meet the T-2 week deadline for the Chicago meeting (which technically expires at 2pm US Central time today -- which is about 3.5 hours from now).

Let me try to summarize the salient points so far:

1. The old text kinda sucks:
   a. it says "macros" (including the section title) where it really means "not interceptable"
   b. p19 implies that these function can only be macros in C (not inlined, and not in Fortran), which seems to contradict p555

2. We need to add the Status conversion functions in there

3. We want to add MPI_SIZEOF (which is Fortran-only, BTW) to the list

4. The use of the word "inline" seems to be a bad idea because it can have many different meanings.  We should say that these functions are not interceptable, which is the real requirement.

5. I think it would be better to change p555 to not say "macros" (i.e., "non-interceptable"), but rather to say "the routines listed in 2.6.4" (i.e., who cares what the reason is -- just cite 2.6.4 and let 2.6.4 explain everything).

Is that all?




On May 19, 2014, at 11:08 AM, Rolf Rabenseifner <rabenseifner at hlrs.de> wrote:

> Yes, the "allowed as macros" on MPI-3.0 p555:32 
> would allow a different mechanism for these routines
> that makes them non-interceptable.
> 
> If this "non-interceptable" is done by other means 
> than macro, then p555:35 "For routines implemented 
> as macros, it is still required that the PMPI_ 
> version be supplied" would not apply!
> 
> It is bad to use different wording for having 
> better English quality ;-(
> 
> And your are right, my "#ifdef MPI_Wait" says 
> therefore nothing.
> 
> Do you all agree that wording in 
> p19:48 - p20:5 and p555:31-37 is at all inconsistent
> and therefore new and useful wording is needed
> in this erratum?
> 
> Rolf 
> 
> ----- Original Message -----
>> From: "N.M. Maclaren" <nmm1 at cam.ac.uk>
>> To: "MPI-WG Fortran working group" <mpiwg-fortran at lists.mpi-forum.org>
>> Sent: Monday, May 19, 2014 4:35:10 PM
>> Subject: Re: [MPIWG Fortran] [mpiwg-tools] Proposal: MPI_SIZEOF not profiled
>> 
>> On May 19 2014, Rolf Rabenseifner wrote:
>>> 
>>> Bill,
>>> 
>>> your text goes beyond the errata goal.
>>> 
>>> The errata goal was:
>>> - adding the missing Status conversion
>>> - adding MPI_SIZEOF
>>> 
>>> And this works as errata.
>>> 
>>> Your goal is to allow also
>>> - Fortran non-interceptable for these routines.
>>> 
>>> Your additional Change is to allow other methods
>>> than C macros for C.
>>> This would prevent "#ifdef MPI_Wtime".
>>> 
>>> All this would be MPI-4.0 and not MPI-3.0 errata.
>> 
>> Would it?  I don't know what useful effect you would expect
>> "#ifdef MPI_Wtime" to achieve, but it assuredly would NOT tell
>> you (reliably) whether or not it can be accessed through the
>> profiling interface.  14.2 says:
>> 
>>    1. provide a mechanism through which all of the MPI defined
>>    functions, except those allowed as macros (See Section 2.6.4),
>>    may be accessed with a name shift.
>> 
>> Because it says "ALLOWED as macros", MPI_Wtime may not be accessed
>> through the profiling interface, whether or not it is implemented
>> as a macro.  Doing so is a user error, leading to undefined
>> behaviour.
>> Therefore, an implementation may implement them as C inline
>> functions,
>> and would meet all of the requirements of MPI.
>> 
>> The error is more pervasive than just for Fortran.  Because it did
>> not say what it meant, but something that was equivalent under K&R C
>> (sic), it wasn't strictly true in C90 and was rendered significantly
>> misleading (arguably erroneous) by C99.  And that's the reason that
>> some people get very unhappy about the proposed partial fix.
>> 
>> It's also why the best solution is to regard ALL of the wording as
>> an error - which would probably mean starting a new ticket.  But it's
>> definitely an error in the wording, not a change.
>> 
>> 
>> Regards,
>> Nick Maclaren.
>> 
>> _______________________________________________
>> mpiwg-fortran mailing list
>> mpiwg-fortran at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran
>> 
> 
> -- 
> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
> Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)
> _______________________________________________
> mpiwg-fortran mailing list
> mpiwg-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran


-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/




More information about the mpiwg-tools mailing list