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

Martin Schulz schulzm at llnl.gov
Mon May 19 18:40:26 CDT 2014 

Hi Rolf,

I agree and (I think) so does Jeff - I think Jeff’s point was only that we
should take the time and get the wording right. We can still bring this up
as an errata item in Japan and it will get into MPI 3.1.

Sound OK?

Martin

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








On 5/19/14, 1:49 PM, "Rolf Rabenseifner" <rabenseifner at hlrs.de> wrote:

>I'll be not at the June Meeting in Chicago. My apologies.
>
>For me, the solution is now nearly clear:
>Allow for all these special cases that they are non-interceptable,
>and require that the PMPI Version is still available,
>and to mention "macro in C" only as an "e.g.",
>and the list includes the existing list plus MPI_SIZEOF
>plus status conversion routines.
>Du to the problems in the existing wording, and with MPI_SIZEOF,
>I would propose it as an erratum, that is needed for MPI-3.1.
>
>Best regards
>Rolf
>
>----- Original Message -----
>> From: "Jeff Squyres (jsquyres)" <jsquyres at cisco.com>
>> To: "MPI-WG Fortran working group" <mpiwg-fortran at lists.mpi-forum.org>
>> Cc: mpiwg-tools at lists.mpi-forum.org
>> Sent: Monday, May 19, 2014 8:19:58 PM
>> Subject: Re: [mpiwg-tools] [MPIWG Fortran] Proposal: MPI_SIZEOF not
>>profiled
>> 
>> Ok.  Will any other Fortran people be there?  (besides me)
>> 
>> 
>> On May 19, 2014, at 2:03 PM, Martin Schulz <schulzm at llnl.gov> wrote:
>> 
>> > 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
>> > 
>> > 
>> > _______________________________________________
>> > 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
>> 
>
>-- 
>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-tools mailing list
>mpiwg-tools at lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

More information about the mpiwg-tools mailing list