(j3.2006) [ukfortran] (SC22WG5.5059) WG5 vote on draft TS on further coarray features

[N.M. Maclaren]

On Aug 5 2013, Bill Long wrote:
>>>>>
>>>>> > Passim. The specification is messy and restrictive, and should be
>>>>> > changed. For example, it is not possible to reduce INTENT(IN) >
>>>>> examples.
>>>
>>> The INTENT(IN) case seems too trivial to justify changing a spec that
>>> is increasingly in production use.  If you want
>>>
>>> co_sum( <expr>, X)
>>>
>>> just write
>>>
>>> X = <expr>
>>> co_sum(X)
>>>
>>> instead.  The second form avoids the compiler having to create a temp
>>> for <expr>, which you would want to avoid anyway if X is an array.
>>
>> Er, no, it doesn't.  You have just created a named temporary: X.
>
>Huih?  X is the RESULT argument in the first example. It is where the 
>user wants the answer.  It has to be an already existing variable, not a 
>temp.

That is only the case when you want the result on all images.

I also forgot to mention that this needs an EXTRA copy in all cases,
which can cause a LOT of inefficiency.  Like this:

    With the two-argument form, the source is read once and the result
written once.
    With your solution, the source is read, the result written, the
result read and the result written.

>> Indeed, one of the main reasons to want a proper two-argument form
>> IS to avoid an unnecessary array copy and the consequent inefficient
>> use of space.
>
>Quite the opposite.  The one-argument form uses less space.  The 
>two-argument form requires double the space.  The two-argument form, 
>indeed, involves a copy from SOURCE to RESULT as part of the operation, 
>since we are not changing the value of SOURCE.

Again, not in the case when only one image wants the result.

>> Consider a large number of images and reducing onto a single result
>> image.  You are now forcing all of the other images to copy the input
>> argument.
>
>If SOURCE is INTENT(IN) such a copy is required anyway.

Why on earth is that needed?  MPI doesn't do that.

> If SOURCE is 
>left INTENT(INOUT) then the copy can be avoided.

Not in well-engineered code, where read-only arguments are INTENT(IN).
For heaven's sake, let's not go introduce features where good software
engineering is incompatible with performance - that way lies C++!

>The time for the copy 
>is independent of the number of images, so it is not that material. 
>Making a new temp is potentially the more problematic action.

NO, it is NOT - not on any current multi-core system.  None of them
have enough memory system capacity to allow all cores to opy data in
parallel (or, often and increasingly, more than a very small number
of them).

The point is that, for every user who uses machines like the ones you
are aiming for, there are tens or hundreds who use commodity desktops
and small servers.  And, if Fortran coarrays run like a drain if each
image is assigned to a core, that's a very, very bad idea.


Regards,
Nick Maclaren.