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

Mon May 19 13:03:36 CDT 2014

Yes, sounds like it - I¹ll take 428 off the list then. We should take some
time on Monday afternoon as part of the tools WG time to talk about this.

Martin

________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://scalability.llnl.gov/
CASC @ Lawrence Livermore National Laboratory, Livermore, USA

On 5/19/14, 8:35 AM, "Jeff Squyres (jsquyres)" <jsquyres at cisco.com> wrote:

>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/
>
>_______________________________________________
>mpiwg-tools mailing list
>mpiwg-tools at lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools