[MPI3 Fortran] Results from the Fortran plenary session yesterday

[Jeff Squyres]

Nick --

Thanks for your comments!  I'll reply in more detail later (we're still meeting in the Forum now); Rolf changed his slides as he presented them to the Forum to incorporate feedback -- at least some of your points have been addressed.  Here's a final copy of his slides:

     http://meetings.mpi-forum.org/secretary/2010/10/slides.php

More later.



On Oct 12, 2010, at 1:20 PM, N.M. Maclaren wrote:

> Thank you for posting this.  Here are some comments on the substantive
> issues, referring to the tickets as needed.  Please note that they are
> my personal ones, and I am not speaking for WG5 or anyone else.
> 
> 
> Page 4.  As you know, some of us are working on this in WG5 and J3.
> 
> 
> #232.  This is a mistake.  Some compilers do not have such hacks, and
> it isn't desirable to forbid them to support a MPI module, especially if
> they do at present.  The words "if possible" should be added.
> 
> 
> Page 14.  A Technical Report is, indeed, 'official', but it is also
> optional on vendors.  Most have stated that they will support at least
> the parts that MPI needs.  The current TR is definitely unstable, though
> TYPE(*) and DIMENSION(..) are among the stable parts.
> 
> 
> #236.  The Fortran term is 'array sections'.
> 
> There is no realistic change of vector subscripts being permitted for
> use as buffers in non-blocking calls, so it's a permanent restriction.
> 
> 
> #237.  Please be careful.  It would be terribly easy to specify more
> than is guaranteed or reliable.
> 
> 
> #238.  The word 'register' should be removed, effectively throughout
> 16.2, as the majority of problems have nothing to do with registers.
> It is misleading.
> 
> I can find no reference to TARGET in ticket #238.  As I believe that you
> may intend to say, the advice on using one-sided communication should
> be that the TARGET attribute on the window is adequate for active
> one-sided communication, but VOLATILE is needed for passive.
> 
> Actually, I believe that ASYNCHRONOUS would do as well, but should
> prefer to run that one past WG5.
> 
> The proposed solution is incorrect.  Even if the variables are stored
> in modules or COMMON blocks, the VOLATILE or TARGET attribute is still
> needed.  The data may not go away, but a compiler is allowed to make
> several assumptions that are incompatible with one-sided communication.
> VOLATILE or TARGET is both necessary and sufficient.
> 
> On this topic, it is NOT possible for MPI implementations to avoid this
> for conforming C programs, with a strict interpretation of the C
> standard, but the C standard is such a mess that there is no point in
> trying to say anything else.  And, yes, it really does cause trouble.
> If anyone is interested, I can describe some of the issues, but I
> suggest just ignoring the matter.
> 
> I suggest playing down that DD() trick, as it is VERY deceptive.  In
> particular, as soon as a user enables significant optimisation, it is
> likely to trigger global optimisation and inlining, which will stop
> the trick from working!  The ways of preventing that are so repulsive
> that you don't want to describe them - and are unreliable anyway.
> 
> MPI_F_SYNC_REG/MPI_SYNC_REG/MPI_FLUSH_REG is a really bad idea.  It has
> been tried many times in many interfaces, and has never worked reliably.
> That is both because flushing registers is a compiler and not a library
> issue and because the problems often occur in a calling procedure.  For
> a specification that attempts to take this approach and get it right,
> look at the IA64 architecture, especially with regard to unwind
> sections.  My executive summary is "Don't go there".
> 
> 
> #242.  Unless I have missed something more than usually subtle, this
> ticket misunderstands the meaning of INTENT(IN).  There is no problem in
> specifying it for ALL input-only arguments, as it would not stop MPI
> 'constants' from being passed.  It constrains the use of the argument
> and not the actual argument.
> 
> Not specifying INTENT(IN) has a lot of harmful effects, including
> degraded optimisation.
> 
> Why do people believe that there is a problem?
> 
> 
> #246.  This is a really good idea because, inter alia, 'Cray pointers'
> are seriously non-portable even to compilers that claim to support them.
> However, it's more than a description - it's a change of specification.
> 
> Do you need help with the specification of the new interface?
> 
> 
> 
> Regards,
> Nick Maclaren.
> 
> 
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran


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