I have a question regarding the legality of the following code,
Is the code below OK? More specifically, how would an MPI-based implementation do this? The call to foo will result in a local
allocation, but how this could be broadcast to all other images
is not clear to me.
module x
implicit none
type mytype
integer :: x
end type mytype
type foobar
type(mytype), allocatable:: xyz
end type
type(foobar):: arr[*]
contains
subroutine bar()
if (mod(this_image(), 2) .eq. 1) then
call foo(arr%xyz)
else
sync all
print *, arr[this_image() - 1]%xyz%x
end if
end subroutine
subroutine foo(a)
type (mytype), intent(inout), allocatable :: a
allocate (a)
a%x = this_image()
sync all
end subroutine foo
end module x
I have a question regarding the legality of the following code,
Is the code below OK? More specifically, how would an MPI-based implementation do this? The call to foo will result in a local
allocation, but how this could be broadcast to all other images
is not clear to me.
Thomas Koenig schrieb am Donnerstag, 18. November 2021 um 23:05:44 UTC+1:
I have a question regarding the legality of the following code,
Is the code below OK? More specifically, how would an MPI-based
implementation do this? The call to foo will result in a local
allocation, but how this could be broadcast to all other images
is not clear to me.
module x
implicit none
type mytype
integer :: x
end type mytype
type foobar
type(mytype), allocatable:: xyz
end type
type(foobar):: arr[*]
contains
subroutine bar()
if (mod(this_image(), 2) .eq. 1) then
call foo(arr%xyz)
else
sync all
print *, arr[this_image() - 1]%xyz%x
end if
end subroutine
subroutine foo(a)
type (mytype), intent(inout), allocatable :: a
allocate (a)
a%x = this_image()
sync all
end subroutine foo
end module x
I believe this is conforming code (possibly modulo syntactic
details, I haven't tried to compile it).
Note that coarrays
of a type with ALLOCATABLE or POINTER components are permitted,
although in general communication performance for these components
will incur additional latencies and other performance issues due
to the nonsymmetric nature of such objects.
I cannot specifically say how an MPI based implementation would
need to do this, but suspect that for this usage active-target
RMA (one-sided MPI_Get on arr[...]%xyz%x with an MPI_Fence as synchronization) would provide the needed properties. I do not
understand your reference to a "broadcast" though. Your code has
~n/2 Gets on all even images to the respective neighbour.
..
The reason why I was asking is a design issue that we are currently
facing desiging the shared memory coarray implementation for gfortran. ..
rbader <Ba...@lrz.de> schrieb:
Thomas Koenig schrieb am Donnerstag, 18. November 2021 um 23:05:44 UTC+1:
I have a question regarding the legality of the following code,
Is the code below OK? More specifically, how would an MPI-based
implementation do this? The call to foo will result in a local
allocation, but how this could be broadcast to all other images
is not clear to me.
module x
implicit none
type mytype
integer :: x
end type mytype
type foobar
type(mytype), allocatable:: xyz
end type
type(foobar):: arr[*]
contains
subroutine bar()
if (mod(this_image(), 2) .eq. 1) then
call foo(arr%xyz)
else
sync all
print *, arr[this_image() - 1]%xyz%x
end if
end subroutine
subroutine foo(a)
type (mytype), intent(inout), allocatable :: a
allocate (a)
a%x = this_image()
sync all
end subroutine foo
end module x
I believe this is conforming code (possibly modulo syntacticIt does the expected thing with NAG, at least, and NAG being
details, I haven't tried to compile it).
picky, I suspect this is OK.
Note that coarraysOK.
of a type with ALLOCATABLE or POINTER components are permitted,
although in general communication performance for these components
will incur additional latencies and other performance issues due
to the nonsymmetric nature of such objects.
I cannot specifically say how an MPI based implementation wouldSorry, wrong terminology about broadcast. Also, the question
need to do this, but suspect that for this usage active-target
RMA (one-sided MPI_Get on arr[...]%xyz%x with an MPI_Fence as synchronization) would provide the needed properties. I do not
understand your reference to a "broadcast" though. Your code has
~n/2 Gets on all even images to the respective neighbour.
regarding MPI was not really what I was after, some explanation
is in order.
The reason why I was asking is a design issue that we are currently
facing desiging the shared memory coarray implementation for gfortran.
To avoid all sorts of problems, the basic design allocates a large
shared memory segment and then does fork(). All coarrays are then
put into that segment, also all locally allocated allocatables
and pointers (like in the code above).
If code that knows nothing about coarrays allocates or frees
memory, it will (up to now) simply call malloc(), which will
not work. So, we are in discussion how to solve it, preferably
without an ABI change (or replacing malloc() from under
the library).
Hmm...
Thomas Koenig schrieb am Freitag, 19. November 2021 um 18:10:14 UTC+1:
If code that knows nothing about coarrays allocates or frees
memory, it will (up to now) simply call malloc(), which will
not work. So, we are in discussion how to solve it, preferably
without an ABI change (or replacing malloc() from under
the library).
This indeed sounds tricky. In particular with POINTER components, there is no way
for the target (which might be a static variable, or dynamically allocated) to tell
whether it will get used in a coarray context later on.
..
(the sync all before the end of the subroutine to make
sure that foo is still executing and a%ip is still pointing
to something valid). ..
On Friday, November 19, 2021 at 6:39:59 PM UTC-5, Thomas Koenig wrote:This variant is invalid due to a race condition.
..
(the sync all before the end of the subroutine to make
sure that foo is still executing and a%ip is still pointing
to something valid). ..
Intuitively one would think the following would suffice, not sure yet what the standard states (will need to check):
..
if (mod(i,2) == 1) then
a%ip => i
else
print *,a[i-1]%ip
end if
sync all
..
On Friday, November 19, 2021 at 12:10:14 PM UTC-5, Thomas Koenig wrote:
..
The reason why I was asking is a design issue that we are currently
facing desiging the shared memory coarray implementation for gfortran. ..
To @Thomas Koenig and all the GCC/gfortran volunteers involved with this,
Will it be possible for you to announce this effort toward shared memory coarray implementation at the Fortran Discourse site?
https://fortran-lang.discourse.group/
FortranFan <parekhvs@gmail.com> schrieb:
On Friday, November 19, 2021 at 12:10:14 PM UTC-5, Thomas Koenig wrote:
..To @Thomas Koenig and all the GCC/gfortran volunteers involved with this,
The reason why I was asking is a design issue that we are currently
facing desiging the shared memory coarray implementation for gfortran. .. >>
Will it be possible for you to announce this effort toward shared memory coarray implementation at the Fortran Discourse site?
https://fortran-lang.discourse.group/
I will not post in a forum which prescribes "welcoming language".
I feel unwelcome there.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 159 |
Nodes: | 16 (0 / 16) |
Uptime: | 98:05:17 |
Calls: | 3,209 |
Files: | 10,563 |
Messages: | 3,009,574 |