[MPI3 Fortran] Results from the Fortran plenary session yesterday
jsquyres at cisco.com
Tue Oct 12 13:36:13 CDT 2010
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:
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?
> Nick Maclaren.
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
jsquyres at cisco.com
For corporate legal information go to:
More information about the mpiwg-fortran