gmove: not all processors contribute case

[Noriyuki Kushida]

Hi,

Sorry for my frequent questions.

If you have an idea, please help me.

My question is basically, how we can write gmove, when only a part of processes can execute gmove. Please have a look at the code attached. It should be clearer than natural language.

The result (will be copied at the bottom) indicates that I also need to have processes which only receive data participate. However, this is not clear to me how to do.

I also tried 'gmove out async' (and receivers do wait_async), but this looks causing memory leak even though the result might be good (probably, just by chance).

I hope there is an expected scenario in XcalableMP/ACC.

On a different note, regarding multi-GPU node case, I think the attached specification tells the answer. Sorry for the disturbance.

I am using;

Omni Compiler: 1.3.2 with xacc option.

PGI: 20.1

DGX station

Best regards,

Noriyuki Kushida

==== result ====

         1001
         1002
         1003
         1004
            0
            0
            0
            0
         3001
         3002
         3003
         3004
            0
            0
            0
            0

[Noriyuki Kushida]

Hi,

I now find the solution. Sorry for the cumbersome.

I have just realized that gmove also accepts the case that the upper bound of a range is smaller than the lower bound, namely

!$gmove out

   a(-1:-2) = b(-1:-2)

A process which issues this line actually does nothing, but can be involved in gmove.

Best regards,

Noriyuki Kushida

[Hitoshi Murai]

Hi Kushida-san,

It's unfortunate that your solution isn't conforming to XMP. The gmove
construct is "collective" and therefore the parameters in it must be
identical at run time on all executing nodes.

In this case, one possible solution is using the task construct and
gmove out, as follows:

-----------------------
!$xmp task on pp(1)
!$xmp gmove out
a(1:8) = b(1:8)
!$xmp end task
-----------------------

It's not possible to broadcast a local value on a certain node with
normal (i.e. collective) gmove, and you have to use a little tricky way
as above. Actually, we've recognized this is one of the issues about gmove.

Best regards,
Hitoshi Murai

--
村井 <h-m...@riken.jp>