[OpenCoarrays] RFC patch: Dependency/alias analysis wir same-image coarray access

[Tobias Burnus]

Alessandro Fanfarillo wrote:
> At point 3 I was thinking about the simplest case (which regenerated
> the problem) of a MPI_GET/MPI_PUT on the same location.  For these cases (useless copy) the library should ignore the command.

I believe that MPI_Get/MPI_Put also had issues with partially 
overlapping memory and not only with fully overlapping memory; like 
"a(1:5)[1] = a(2:6)" or "a(2:6)[1] = a(1:5)" – I am sure one or both 
versions might make trouble - at least with some MPI implementations.

Additionally, I regard it is a special case of case (2), namely the case 
"if memory source and destination are contiguous."

I wouldn't be surprised if memmove uses "if (s1 == s2) return;" as 
special case. (I check: glibc doesn't). Likewise, you could also add 
such a check in the call. I have no idea how often such a code exists 
(i.e. how worthwhile it is). For caf_sendget it probably is useful for 
the case that the image indexes both point to the same remote (!) image.


However, crucially is really the case (3), where the library has to 
generate a temporary array – independent whether the library handles 
overlapping memory access or not - and independently whether memmove is 
used or not. Prime example is - as I showed before - the case 
"a(10:2:-1)[1] = a(:)" where in a forward access to the memory, you have 
already overridden the memory location with a value before you read from 
it. (In that case, it helps what memmove does in that case: If you 
cannot walk forward, then walk backwards. But with multiple dimensions, 
one can create more complicated pattern.)

Tobias

> Point 2 means that memmove should be applied for any case with source
> and target on the same image, even for non-contiguous memory areas.
>
> It sounds reasonable to me; what do you think?
>
>
> On Wed, Aug 27, 2014 at 1:29 PM, Tobias Burnus <burnus@net-b.de> wrote:
>> Alessandro Fanfarillo wrote:
>>> The compiler participation could be useful for performance purposes.
>>> The idea is:
>>>
>>> 1) the library checks if source and destination are the same and if
>>> the compiler finds an aliasing.
>>
>> I assume you mean: source and target are on the same image. (Which for
>> caf_sendget might be not the executing one.)
>>
>>
>>> 2) If the compiler does not find anything, the library just applies
>>> memmove.
>>
>> Ditto if memory source and destination are contiguous. That's in line with
>> the current compiler check but can in general only be done at run time -
>> and, for performance reasons, this check is already done. (One could also
>> check more as the compiler cannot do all checks at compile time; one could
>> also support walking the array in reverse order etc. However, I don't think
>> that's worthwhile.)
>>
>>
>>> 3) If the compiler find an aliasing, the library does not do anything.
>>
>> I do not understand your 3: If the library doesn't do anything, you get
>> wrong results for
>>    a(5:1:-1)[1] = a(1:5:1)
>>
>> I think what one wants is the following: The library creates a temporary
>> array and first assigns to it - before assigning from the temporary to the
>> target variable.
>>
>>
>> Tobias
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "OpenCoarrays" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to opencoarrays+unsubscribe@googlegroups.com.
>> Visit this group at http://groups.google.com/group/opencoarrays.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/opencoarrays/53FE317F.4070803%40net-b.de.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>