Coarray exploitation

[szaghi]

Exploit coarray to make hash table a massively parallel container is a challenging aim, probably I'll be not up to the task. To start I have to deeply study the work of @MichaelSiehl

• https://github.com/MichaelSiehl/MPMD-with-Coarray-Fortran-Load-Balancing-Example-Program
• https://github.com/MichaelSiehl/Coarray_Test_Program_for_Character_Data
• https://github.com/MichaelSiehl/MPMD-with-Coarray-Fortran-TS-18508-Events-Example-Program
• https://groups.google.com/forum/m/#!topic/opencoarrays/E-hbLfOpD98

[MichaelSiehl]

Hi Stefano, I will update these Github repositories within the next days by adding new code versions using F2008 SYNC MEMORY and atomic subroutines. The current code versions do work with the compilers but are not confoming to the (F2008/15) standard. I can already tell that the Load Balancing Example does work using SYNC MEMORY and atomic subroutines: Since the synchronizations are still coded 'manually', it is possible to synchronize between objects on the same coarray image. Nevertheless, I was unable to achieve something similar using F2015 Events: From my current practical experiences you can use Events only for synchronizations between distinct coarray images. It is important to notice that the use of SYNC MEMORY does form execution segments which are unordered within the example program. Best regards Michael

[szaghi]

Dear @MichaelSiehl ,

You are very kind, I was not expecting to bother you so early, I have to study with much more care your great work. Anyhow, just because you mentioned the topic, I like to start our corrispondence 😄

Your approach for obtaining MPMD is foundamental for me to exploit coarray for this generic container. The events of F2015 are not necessary, your sync method should be definitely perfect for my aims.

My main concerns are twofold:

• my very basic knowldge of coarray (the big issue);
• the possible immaturity of coarray implementaions of compilers (weak issue).

In particular, for this project (that seems a stupid toy, but it is a very foundamental block for others...), I need to obtain a generic container that entails MPMD features. It is passed one half of year from my last view, but I remember that there were issues to encapsulate your MPMD technique into an object, namely building a OOP class entailing your MPMD approach. Is this still an issue, or you have built derived types encapsulating MPMD features?

At some point I would like to talk wiyh all other members of the group (e.g. @rouson and @zbeekman) but for now I have to study. Nevertheless, if you are so kind, I like to bother you even during my coarray-training period, this could be of great help for me.

Cheers.

[zbeekman]

I know one potential limitation---which is almost fixed---is the use of allocatable components of derived type coarrays was not supported by GCC/OpenCoarrays until some of the latest patches to GCC are merged, and the support for this is finalized in OpenCoarrays. In the near future, code such as the following will now be possible using GCC-7 (AKA GCC trunk, until the 7.1 release in the spring) in combination with an OpenCoarrays future release:

type foo
   real, allocatable :: bar(:)
end type
type(foo) :: foobar[*]

It is possible that there are unexercised bugs in OpenCoarrays, but the more people use it and report back to us, the faster we can resolve them. Anyway, @rouson is the real expert here, so my apologies if I've misinterpreted anything.

[szaghi]

@zbeekman I was thinking just this issue that I have tagged weak in the previous post. As I said I need a lot of time to study MPMD technique of @MichaelSiehl , thus for the time I'll be ready I am sure that the implementations (opencoaray/GNU gfortran) supporting caf will be bullet-proof 😄

[MichaelSiehl]

Hi Izaak,
that is great news. I do not use these in my current coarray programming,
but did some testing with ifort
some time ago. I did post two small test programs utilizing allocatable
components of derived type coarrays here:
https://groups.google.com/forum/#!topic/opencoarrays/E-hbLfOpD98

Best Regards

2016-10-02 16:12 GMT+02:00 Izaak Beekman notifications@github.com:

I know one potential limitation---which is almost fixed---is the use of
allocatable components of derived type coarrays was not supported by
GCC/OpenCoarrays until some of the latest patches to GCC are merged, and
the support for this is finalized in OpenCoarrays. In the near future, code
such as the following will now be possible using GCC-7 (AKA GCC trunk,
until the 7.1 release in the spring) in combination with an OpenCoarrays
future release:

type foo
real, allocatable :: bar(:)end typetype(foo) :: foobar[*]

It is possible that there are unexercised bugs in OpenCoarrays, but the
more people use it and report back to us, the faster we can resolve them.
Anyway, @rouson https://github.com/rouson is the real expert here, so
my apologies if I've misinterpreted anything.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AQUQ_OEVHDireSpsBhGwgMQ186E62JWnks5qv7u4gaJpZM4KL8mp
.

[zbeekman]

@rouson: We may want to incorporate tests like @MichaelSiehl's into OpenCoarrays. @szaghi sorry for hijacking your thread 😄 🔫

[szaghi]

@zbeekman you can do wather you want, you are one of my heroes 😄

I hope in the near future HASTY will give to OpenCoarrays team a challenging test, but I am not sure I'll be up to the task (at least without your kind help 🙏 ).

Cheers.

P.S. @rouson FLAP install script is coming soon.

[MichaelSiehl]

Regarding allocatable components of derived type coarrays, I would also
like to point to the following code snippet from my second test program
(using ifort):

IF (Coarray_Object[intImageNumber] % logAllocationStatus) THEN
intLowerBound = LBOUND (Coarray_Object[intImageNumber] % reaDataArray, 1)
intUpperBound = UBOUND (Coarray_Object[intImageNumber] % reaDataArray, 1)
ELSE
intLowerBound = 1
intUpperBound = 0
END IF

As far as I remember, ifort did allow to use the LBOUND and UBOUND
intrinsics to request the array bounds (of such non-symetric coarrays)
from a remote image.

2016-10-03 23:13 GMT+02:00 Stefano Zaghi notifications@github.com:

@zbeekman https://github.com/zbeekman you can do wather you want, you
are one of my heroes 😄

I hope in the near future HASTY will give to OpenCoarrays team a challenging
test, but I am not sure I'll be up to the task (at least without your
kind help 🙏 ).

Cheers.

P.S. @rouson https://github.com/rouson FLAP install script is coming
soon.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AQUQ_JZSrzgSQpQyh441agLbCe-jmoiEks5qwW_xgaJpZM4KL8mp
.

[MichaelSiehl]

|My main concerns are twofold:

• |my very basic knowldge of coarray (the big issue);
• |the possible immaturity of coarray implementaions of compilers
  (weak issue).

|In particular, for this project (that seems a stupid toy, but it is a very
foundamental block for others...), I need to obtain a generic container
that entails MPMD features. |It is passed one half of year from my last
view, but I remember that there were issues to encapsulate your MPMD
technique into an object, namely building a OOP |class entailing your MPMD
approach. Is this still an issue, or you have built derived types
encapsulating MPMD features?

|At some point I would like to talk wiyh all other members of the group
(e.g. @rouson https://github.com/rouson and @zbeekman
https://github.com/zbeekman) but for now I have to study. Nevertheless,
if you are so kind, I |like to bother you even during my coarray-training
period, this could be of great help for me.
Hi Stefano,
it is important to note that the F2008 MPMD-style is still an experiment.
My current main focus is on atomic subroutines and SYNC MEMORY (and its
limitatons and possible pitfalls). Upcomming F2015 Teams may be a more
convenient way to deploy MPMD-style programming techniques. The F2008
techniques I show do require much more framework development for safe use
in real-world parallel programming. With the use of SYNC MEMORY I do enter
the world of unordered execution segments: I may use Fortran 2008 means to
stear the parallel program execution in a conforming way (using logical and
integer scalars), but, as far as my current understanding goes, all further
data transfer (array data, character, real, etc.) can't be done in a
standard conforming way only with Fortran 2008 means. Thus, it is important
to note that we are just entering the world of MPMD-style parallel
programming using coarrays with the current F2008 standard. The main
advantage of my current approach is the ability to maintain a
sequential-like syntax within my parallel programming.
Regarding OOP: I believe the real power of coarrays lies in the ability to
use them in conjunction with objects (derived type coarrays). But at the
same time, coarrays are very limited for use with polymorphism and
inheritence (the main means for code reuse with OOP). Another means for
code reuse is delegation, which I also do not use with my F95-style coarray
object wrappers. Finally, the only code reuse technique I use with my
coarray wrappers is a (primitive) code generation technique we've developed
in the 1990s for sequential programming (it does not work perfectly with
the coarray wrappers yet).
I hope this helps a little bit.
cheers ;-)

[MichaelSiehl]

I just created a new GitHub repository containing the above example program
(to illustrate the use of a derived type coarray with an allocatable
component). Feel free to use it or change it for your needs. While my
current version of OpenCoarrays/gfortran does not support the syntax of the
example code, it does perfectly point to those language elements it does
not support yet.
https://github.com/MichaelSiehl/Coarray-with-Allocatable-Component-Example

2016-10-05 1:22 GMT+02:00 michael siehl miesiehl@gmail.com:

|My main concerns are twofold:

• |my very basic knowldge of coarray (the big issue);
• |the possible immaturity of coarray implementaions of compilers
  (weak issue).

|In particular, for this project (that seems a stupid toy, but it is a
very foundamental block for others...), I need to obtain a generic
container that entails MPMD features. |It is passed one half of year
from my last view, but I remember that there were issues to encapsulate
your MPMD technique into an object, namely building a OOP |class entailing
your MPMD approach. Is this still an issue, or you have built derived types
encapsulating MPMD features?

|At some point I would like to talk wiyh all other members of the group
(e.g. @rouson https://github.com/rouson and @zbeekman
https://github.com/zbeekman) but for now I have to study. Nevertheless,
if you are so kind, I |like to bother you even during my coarray-training
period, this could be of great help for me.
Hi Stefano,
it is important to note that the F2008 MPMD-style is still an experiment.
My current main focus is on atomic subroutines and SYNC MEMORY (and its
limitatons and possible pitfalls). Upcomming F2015 Teams may be a more
convenient way to deploy MPMD-style programming techniques. The F2008
techniques I show do require much more framework development for safe use
in real-world parallel programming. With the use of SYNC MEMORY I do enter
the world of unordered execution segments: I may use Fortran 2008 means to
stear the parallel program execution in a conforming way (using logical and
integer scalars), but, as far as my current understanding goes, all further
data transfer (array data, character, real, etc.) can't be done in a
standard conforming way only with Fortran 2008 means. Thus, it is important
to note that we are just entering the world of MPMD-style parallel
programming using coarrays with the current F2008 standard. The main
advantage of my current approach is the ability to maintain a
sequential-like syntax within my parallel programming.
Regarding OOP: I believe the real power of coarrays lies in the ability to
use them in conjunction with objects (derived type coarrays). But at the
same time, coarrays are very limited for use with polymorphism and
inheritence (the main means for code reuse with OOP). Another means for
code reuse is delegation, which I also do not use with my F95-style coarray
object wrappers. Finally, the only code reuse technique I use with my
coarray wrappers is a (primitive) code generation technique we've developed
in the 1990s for sequential programming (it does not work perfectly with
the coarray wrappers yet).
I hope this helps a little bit.
cheers ;-)

[zbeekman]

@MichaelSiehl would you be willing to submit this as a test case to OpenCoarrays, to test our implementation once it goes live?

CC: @rouson

[MichaelSiehl]

@zbeekman: Yes, of course. The code compiles and runs well with ifort. Does submitting this as a test case to OpenCoarrays require any further steps by myself or can you do it yourself?
cheers

[zbeekman]

I think the one thing that should probably happen is that you open a pull
request to trigger the CLA (Contributor License Agreement) assistant, just
so that you acknowledge that you're contributing the code, rather than us
stealing it. Let's hold off for now, I have a trip coming up this week, but
I can help walk you through it when I return next week.

On Fri, Oct 14, 2016 at 4:49 PM Michael Siehl notifications@github.com
wrote:

@zbeekman https://github.com/zbeekman: Yes, of course. The code
compiles and runs well with ifort. Does submitting this as a test case to
OpenCoarrays require any further steps by myself or can you do it yourself?
cheers

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAREPCBCGZ4qZelmU5MwIpRbJ77mTbBNks5qz-rlgaJpZM4KL8mp
.