info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
What can we (already) do with Coarray Fortran?
123 views
Skip to first unread message
michael siehl
Feb 9, 2015, 6:35:10 PM2/9/15
to
Hi all,
this is meant as a small contribution to a better understanding of Coarray Fortran's usefulness from a developer's view. It's partly based on my own programing experiences with CAF, but also based on my current understanding of some of its concepts I could not use in practice yet. Therefore, I might be wrong with some points. Comments are welcome.
To answer the initial question, I'd like to make a distinction into 3 different types of coarrays: (1)symmetric coarrays of Fortran 2008, (2)non-symmetric coarrays of Fortran 2008, and (3)symmetric coarrays with the planned TEAM facility of TS18508. (Please refer to Aleksandar Donev's 'Rationale for Co-Arrays in Fortran 2008' paper for much better insights into the different coarray concepts of Fortran 2008.)
(1)Symmetric coarrays of Fortran 2008 embrace almost all kinds of coarrays except derived type coarrays with allocatable or pointer components. (A further exception might be allocatable coarray components). They are useful if one needs to develop a rather simple SPMD program. This type of coarray exists always on all Images and, if needed dynamically, implies an implicit barrier synchronization over all Images whenever allocated or deallocated. (This is also true for allocatable coarray components.) I've not used them in practice because of the obvious limitations for my own software projects. Nevertheless, symmetric coarrays stand for the real power of CAF because of their unique optimization opportunities. (See Aleksandar Donev's paper for good explanations.)
(2)Non-symmetric coarrays of Fortran 2008 are derived type coarrays with allocatable or pointer components. This is the type of coarray I am using extensively at the time. Non-symmetric coarrays make it possible to use also a very powerful MPMD-like style with Coarray Fortran, which may handle a much wider range of parallel software development problems. The use of derived type coarrays with allocatable or pointer components allows to use PGAS memory dynamically without an implicit barrier synchronization. Further, we can use PGAS memory on one Image completely different and independent from the other Images. On the downside, when using non-symmetric coarrays, we are loosing the unique optimization opportunities of CAF and it may require somewhat more burden to the programer to use them efficiently. Still, if you have done some Fortran framework development before, you may find non-symmetric coarrays rather natural and easy to use in your development. More importantly, you may hardly detect any limits of what can already be done with CAF in Fortran 2008. I am pretty sure, we can easily encapsulate the required CAF functionality in an object based fashion and thus make parallel programing much less error prone, we already can group Images into teams, we can treat single Images or groups of Images as completely independent from other parts of the software, we already can detect failed Images and handle them appropriate, or we can develop a task pool management, just to mention a few of the possibilities.
(3)Symmetric coarrays with the planned TEAM facility of TS18508 are currently announced for the next upcoming Fotran standard. I sure expect much of the current non-symmetric coarray possibilities to become true also for these upcoming symmetric coarrays, added with the unique optimization opportunities of CAF and with even less burden to the programer. I believe the addition of the TEAM facility will eventually reveal the real power of Coarray Fortran. If I could choose only one of the mentioned coarray types, I would certainly take symmetric coarrays with the planned TEAM facility. For my expected future software projects I can clearly see the need for doing multiple simultaneous SPMD computations all the time.
Meanwhile, I personally do focus on further framework development with non-symmetric coarrays and expect them to stay relevant because of their great flexibility and do also expect them for good coexistence with the upcoming symmetric coarray TEAMs.
Best regards
Michael
this is meant as a small contribution to a better understanding of Coarray Fortran's usefulness from a developer's view. It's partly based on my own programing experiences with CAF, but also based on my current understanding of some of its concepts I could not use in practice yet. Therefore, I might be wrong with some points. Comments are welcome.
To answer the initial question, I'd like to make a distinction into 3 different types of coarrays: (1)symmetric coarrays of Fortran 2008, (2)non-symmetric coarrays of Fortran 2008, and (3)symmetric coarrays with the planned TEAM facility of TS18508. (Please refer to Aleksandar Donev's 'Rationale for Co-Arrays in Fortran 2008' paper for much better insights into the different coarray concepts of Fortran 2008.)
(1)Symmetric coarrays of Fortran 2008 embrace almost all kinds of coarrays except derived type coarrays with allocatable or pointer components. (A further exception might be allocatable coarray components). They are useful if one needs to develop a rather simple SPMD program. This type of coarray exists always on all Images and, if needed dynamically, implies an implicit barrier synchronization over all Images whenever allocated or deallocated. (This is also true for allocatable coarray components.) I've not used them in practice because of the obvious limitations for my own software projects. Nevertheless, symmetric coarrays stand for the real power of CAF because of their unique optimization opportunities. (See Aleksandar Donev's paper for good explanations.)
(2)Non-symmetric coarrays of Fortran 2008 are derived type coarrays with allocatable or pointer components. This is the type of coarray I am using extensively at the time. Non-symmetric coarrays make it possible to use also a very powerful MPMD-like style with Coarray Fortran, which may handle a much wider range of parallel software development problems. The use of derived type coarrays with allocatable or pointer components allows to use PGAS memory dynamically without an implicit barrier synchronization. Further, we can use PGAS memory on one Image completely different and independent from the other Images. On the downside, when using non-symmetric coarrays, we are loosing the unique optimization opportunities of CAF and it may require somewhat more burden to the programer to use them efficiently. Still, if you have done some Fortran framework development before, you may find non-symmetric coarrays rather natural and easy to use in your development. More importantly, you may hardly detect any limits of what can already be done with CAF in Fortran 2008. I am pretty sure, we can easily encapsulate the required CAF functionality in an object based fashion and thus make parallel programing much less error prone, we already can group Images into teams, we can treat single Images or groups of Images as completely independent from other parts of the software, we already can detect failed Images and handle them appropriate, or we can develop a task pool management, just to mention a few of the possibilities.
(3)Symmetric coarrays with the planned TEAM facility of TS18508 are currently announced for the next upcoming Fotran standard. I sure expect much of the current non-symmetric coarray possibilities to become true also for these upcoming symmetric coarrays, added with the unique optimization opportunities of CAF and with even less burden to the programer. I believe the addition of the TEAM facility will eventually reveal the real power of Coarray Fortran. If I could choose only one of the mentioned coarray types, I would certainly take symmetric coarrays with the planned TEAM facility. For my expected future software projects I can clearly see the need for doing multiple simultaneous SPMD computations all the time.
Meanwhile, I personally do focus on further framework development with non-symmetric coarrays and expect them to stay relevant because of their great flexibility and do also expect them for good coexistence with the upcoming symmetric coarray TEAMs.
Best regards
Michael
Ian Harvey
Feb 9, 2015, 7:19:33 PM2/9/15
to
stumbling block that I think I've come across is that as soon as you
have any sort of CLASS in your program, coarrays become quite difficult
to use. It is as if the coarray part of the language was written in
complete isolation of the polymorphic features, with the only
interaction being the restrictions to stop them interacting.
Is my understanding right? Can you transfer a polymorphic value from
one image to another, without having to write lots of code to somehow
serialise the value?
TYPE :: parent
!.. whatever...
END TYPE parent
TYPE :: t
CLASS(parent), ALLOCATABLE :: x
END TYPE t
TYPE(t) :: coarray[*]
CLASS(Parent), ALLOCATABLE :: y
! on image one...
y = coarray[2]%x
Richard Maine
Feb 9, 2015, 7:34:40 PM2/9/15
to
Ian Harvey <ian_h...@bigpond.com> wrote:
> It is as if the coarray part of the language was written in
> complete isolation of the polymorphic features, with the only
> interaction being the restrictions to stop them interacting.
I'm sure I'm being too harsh in my interpretation of the arguments that
> It is as if the coarray part of the language was written in
> complete isolation of the polymorphic features, with the only
> interaction being the restrictions to stop them interacting.
were made, but the above acutally sounds to me an awful lot like
arguments that were given by the "for" side on f2008. I strenuously
argued that f2008 was way too early because there wasn't yet experience
with f2003 when f2008 was being developed. I recall that my objection
was met with arguments that the new stuff in f2008 (most notably
coarrays) didn't have much interaction with f2003, so it didn't need
f2003 experience.
I didn't like that argument, but that's what I recall hearing.
Sure sounds to me like the same thing you mention above, but with a
positive spin put on it.
--
Richard Maine
email: last name at domain . net
domain: summer-triangle
Wolfgang Kilian
Feb 10, 2015, 4:37:37 AM2/10/15
to
derived types and what isn't. Any source apart from the 2008 standard
and the new TR?
Do I understand correctly that allocatable components are allowed but
polymorphic components are forbidden ... what about data/implementation
hiding? Can I declare and call type-bound procedures for a type, used
for a coarray object?
If there are really restrictions like this, the concept appears rather
unfinished, reminding me of the state of allocatables in the original
F90 standard ...
(Obviously, I've not tried coarrays in real code yet.)
-- Wolfgang
--
E-mail: firstnameini...@domain.de
Domain: yahoo
michael siehl
Feb 10, 2015, 12:37:21 PM2/10/15
to
thanks very much for the comments. Some further clarification from my side seems to be required, because otherwise my above post could be rather misleading.
(A)I do use non-symmetric coarrays, resp. PGAS memory, only for an as sparse as possible communication and data transfer between Images, but not within the program logic code itself. (Therefore the object based encapsulation of the required CAF functionality). Rather, I do copy the transferred data to completely local memory before using it within the program logic code. This makes it possible to write the program logic, even that of a task pool management, in nearly pure Fortran 95/2003 without coarrays.
(B)When I say object based, I do not mean the object oriented (OOP) features of Fortran 2003, but rather the Fortran 95 features for Abstract Data Types (ADT), extended with only some few but powerful features of Fortran 2003. (I have a background with quite a few years of Fortran 95 ADT-Framework development). Therefore, using coarrays in conjunction with the OOP features of Fortran 2003 is nothing I personally could advise yet. But of course, with the above mentioned encapsulation of the CAF functionality, it's easy to use Fortran 2003 OOP for the program logic itself. I personally don't use these currently, because I believe the Fortran 95/2003 ADT approach makes it easier to use Fortran's SIMD parallelism for high performance on a single Image too.
best regards
Michael
(A)I do use non-symmetric coarrays, resp. PGAS memory, only for an as sparse as possible communication and data transfer between Images, but not within the program logic code itself. (Therefore the object based encapsulation of the required CAF functionality). Rather, I do copy the transferred data to completely local memory before using it within the program logic code. This makes it possible to write the program logic, even that of a task pool management, in nearly pure Fortran 95/2003 without coarrays.
(B)When I say object based, I do not mean the object oriented (OOP) features of Fortran 2003, but rather the Fortran 95 features for Abstract Data Types (ADT), extended with only some few but powerful features of Fortran 2003. (I have a background with quite a few years of Fortran 95 ADT-Framework development). Therefore, using coarrays in conjunction with the OOP features of Fortran 2003 is nothing I personally could advise yet. But of course, with the above mentioned encapsulation of the CAF functionality, it's easy to use Fortran 2003 OOP for the program logic itself. I personally don't use these currently, because I believe the Fortran 95/2003 ADT approach makes it easier to use Fortran's SIMD parallelism for high performance on a single Image too.
best regards
Michael
michael siehl
Feb 10, 2015, 1:05:52 PM2/10/15
to
>I'd be interested in a concise summary, what is allowed for coarrays of
>derived types and what isn't. Any source apart from the 2008 standard
>and the new TR?
Hi Wolfgang,
>derived types and what isn't. Any source apart from the 2008 standard
>and the new TR?
the best I know for Fortran 2008 coarrays is Aleksandar Donev's paper and chapter 19 of Modern Fortran explained. But that's not a substitute for practical experiences. I've got the most from just trying it out. If you really want to use the F2003 OOP features with coarrays then you should possibly try coarray components (derived types with components which are coarrays). See section 3.1.1 of the mentioned paper and try something out is the best I can advise. In my case it worked well, but I've not used coarray components yet.
regards
michael
0 new messages