(j3.2006) (SC22WG5.3659) [ukfortran] N1755: Request for new features from MPI Forum

[N.M. Maclaren]

On Nov 11 2008, Aleksandar Donev wrote:
>
>>> We should explicitly allow a variable with the ASYNCHRONOUS attribute 
>>> to be modified or examined by means external to the processor, 
>>> similarly to VOLATILE variables. If such a variable is modified or 
>>> examined externally during a segment, that variable must not be 
>>> referenced or define during that segment.
>> 
>> That will introduce performance implications, though perhaps less
>> serious.
>
>Can you be more specific please?

Consider code like the following:

    INTEGER, ASYNCHRONOUS :: fred
    fred = 0
    SYNC MEMORY
    Nothing that uses fred
    SYNC MEMORY
    ... = fred

With your proposal, the compiler has to assume that fred may have changed.
Currently, it does not.

>> But I really don't like the idea of having to teach kiddies about
>> coarrays when they want to learn MPI.
>
>You don't have to. Segments make sense even without co-arrays, as a way 
>to control optimizations (code motion) in order to facilitate 
>interaction with "things" not visible to the compiler.

At a first glance, perhaps, but I don't think that they do in this case.

Consider the restrictions on VOLATILE arguments (e.g. no VALUE and no
INTENT(IN), and the proposal to require it to be set in all scopes or none).
How many of those would you need to add to ASYNCHRONOUS in order to close
loopholes opened by your proposal?

>> What is actually needed is a way of allowing user code to set and clear
>> a variable's pending state, in the sense used in 9.6.4.  While it would
>> be a bit tricky to add to Fortran, it would be semantically clean, and
>> be as efficient as possible.
>
>Sure. But, I can bet that others will have a different feeling about 
>what is "clean" and "efficient". This seems to be the problem here---we 
>are not likely to make any progress...and the issue will remain. 
>Imperfect is better than non-existent, IMO.

Not necessarily.  Look at Algol 60 dynamic OWN variables, Fortran alternate
returns (which were an early form of exception handling) C volatile and many
features of C99 :-(

This one is very simple, anyway.  As far as the program is concerned, MPI
transfers are semantically just a specialised form of I/O.  Does anyone
seriously dispute that?


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679