I just wanted to notify those who are interested in a free compiler supporting Fortran coarrays that this is available in the OpenUH compiler. OpenUH is developed by the HPCTools group at the University of Houston. It is not a full Fortran 2008 implementation. It is based on the Open64 compiler, which support Fortran 95 and *some* Fortran 2003 features. We have implemented the coarray features that were added to Fortran 2008.
You can download a tarball of the prebuilt compiler or, if you wish, access the source code from here:
I am interested in getting feedback from the community on all aspects of the implementation -- performance issues, features that may not be implemented correctly, ease of installation on your particular system, etc.
A few notes about the implementation:
(1) OpenUH should support all the coarray features that are in Fortran 2008. This includes coarrays of basic types and derived types (including coarrays with pointer/allocatable components), the inquiry and transformational functions (this_image, image_index, num_images, ucobound, lcobound), all the sync statements (sync all, sync images, sync memory), locks, critical sections, error stop, and the atomic_define/atomic_ref subroutines.
(2) The runtime can be built against GASNet (1.18.2) or ARMCI (5.0). These are communication libraries designed to support PGAS implementations. If you are using the prebuilt compiler, then you need to download the separate caf-runtime source package and the build/install it into whereever you extracted the compiler. Both GASNet and ARMCI support a variety of networks or may operate in an SMP environment, so they provide good portability.
(3) The compiler name is uhcaf. The launcher program is cafrun. E.g.
# compile the program and links in the necessary runtime libraries:
$ uhcaf sample.f90 -o sample
# run the executable with 4 images, more options available with --help
$ cafrun -n 4 ./sample
(4) Performance is something we're focused on improving. We leverage the bulk-communication capabilities available in GASNet/ARMCI for contiguous and strided accesses across images. Currently, for the program to benefit from this it must be written using the array assignment syntax. For example, this:
x(:) = y(:)[p]
will get you better performance than this:
do i=lbound(x), ubound(x)
x(i) = y(i)[p]
end do
Another performance limitation is the compiler doesn't yet generate non-blocking calls to help overlap your communication and computation, but this is something we're working on and hope to have ready by the end of this year.
I hope the community finds this useful, and again I welcome any feedback or suggestions.
Thanks,
Deepak Eachempati
HPCTools Group
University of Houston
> I just wanted to notify those who are interested in a free compiler > supporting Fortran coarrays that this is available in the OpenUH > compiler. OpenUH is developed by the HPCTools group at the University > of Houston. It is not a full Fortran 2008 implementation. It is based > on the Open64 compiler, which support Fortran 95 and *some* Fortran > 2003 features. We have implemented the coarray features that were added > to Fortran 2008.
> You can download a tarball of the prebuilt compiler or, if you wish, > access the source code from here:
> I am interested in getting feedback from the community on all aspects > of the implementation -- performance issues, features that may not be > implemented correctly, ease of installation on your particular system, > etc.
You did not mention which systems you support. The website only mentions Linux.
That makes it rather hard to install and test on other systems. There are many
variations on Unix from FreeBSD to MacOsX as well as Solaris. Any plans for any
of those?
> (1) OpenUH should support all the coarray features that are in Fortran > 2008. This includes coarrays of basic types and derived types > (including coarrays with pointer/allocatable components), the inquiry > and transformational functions (this_image, image_index, num_images, > ucobound, lcobound), all the sync statements (sync all, sync images, > sync memory), locks, critical sections, error stop, and the > atomic_define/atomic_ref subroutines.
> (2) The runtime can be built against GASNet (1.18.2) or ARMCI (5.0). > These are communication libraries designed to support PGAS > implementations. If you are using the prebuilt compiler, then you need > to download the separate caf-runtime source package and the > build/install it into whereever you extracted the compiler. Both GASNet > and ARMCI support a variety of networks or may operate in an SMP > environment, so they provide good portability.
> (3) The compiler name is uhcaf. The launcher program is cafrun. E.g.
> # compile the program and links in the necessary runtime libraries:
> $ uhcaf sample.f90 -o sample
> # run the executable with 4 images, more options available with --help
> $ cafrun -n 4 ./sample
> (4) Performance is something we're focused on improving. We leverage > the bulk-communication capabilities available in GASNet/ARMCI for > contiguous and strided accesses across images. Currently, for the > program to benefit from this it must be written using the array > assignment syntax. For example, this:
> x(:) = y(:)[p]
> will get you better performance than this:
> do i=lbound(x), ubound(x)
> x(i) = y(i)[p]
> end do
> Another performance limitation is the compiler doesn't yet generate > non-blocking calls to help overlap your communication and computation, > but this is something we're working on and hope to have ready by the > end of this year.
> I hope the community finds this useful, and again I welcome any > feedback or suggestions.
> Thanks,
> Deepak Eachempati
> HPCTools Group
> University of Houston
> > I am interested in getting feedback from the community on all aspects
> > of the implementation -- performance issues, features that may not be
> > implemented correctly, ease of installation on your particular system,
> > etc.
> You did not mention which systems you support. The website only mentions Linux.
> That makes it rather hard to install and test on other systems. There are many
> variations on Unix from FreeBSD to MacOsX as well as Solaris. Any plans for any
> of those?
Unfortunately, at this time we only support Linux and there are no existing plans to support other Unix flavors. Our compiler is actually a branch of Open64, so if in the future Open64 is ported to other Unix variations than we may also merge in that support.
> I just wanted to notify those who are interested in a free compiler
> supporting Fortran coarrays that this is available in the OpenUH compiler.
> OpenUH is developed by the HPCTools group at the University of Houston. It
> is not a full Fortran 2008 implementation. It is based on the Open64
> compiler, which support Fortran 95 and *some* Fortran 2003 features. We
> have implemented the coarray features that were added to Fortran 2008.
> You can download a tarball of the prebuilt compiler or, if you wish,
> access the source code from here:
> I am interested in getting feedback from the community on all aspects of
> the implementation -- performance issues, features that may not be
> implemented correctly, ease of installation on your particular system,
> etc.
> A few notes about the implementation:
> (1) OpenUH should support all the coarray features that are in Fortran
> 2008. This includes coarrays of basic types and derived types (including
> coarrays with pointer/allocatable components), the inquiry and
> transformational functions (this_image, image_index, num_images, ucobound,
> lcobound), all the sync statements (sync all, sync images, sync memory),
> locks, critical sections, error stop, and the atomic_define/atomic_ref
> subroutines.
> (2) The runtime can be built against GASNet (1.18.2) or ARMCI (5.0). These
> are communication libraries designed to support PGAS implementations. If
> you are using the prebuilt compiler, then you need to download the
> separate caf-runtime source package and the build/install it into
> whereever you extracted the compiler. Both GASNet and ARMCI support a
> variety of networks or may operate in an SMP environment, so they provide
> good portability.
> (3) The compiler name is uhcaf. The launcher program is cafrun. E.g.
> # compile the program and links in the necessary runtime libraries:
> $ uhcaf sample.f90 -o sample
> # run the executable with 4 images, more options available with --help
> $ cafrun -n 4 ./sample
> (4) Performance is something we're focused on improving. We leverage the
> bulk-communication capabilities available in GASNet/ARMCI for contiguous
> and strided accesses across images. Currently, for the program to benefit
> from this it must be written using the array assignment syntax. For
> example, this:
> x(:) = y(:)[p]
> will get you better performance than this:
> do i=lbound(x), ubound(x)
> x(i) = y(i)[p]
> end do
> Another performance limitation is the compiler doesn't yet generate
> non-blocking calls to help overlap your communication and computation, but
> this is something we're working on and hope to have ready by the end of
> this year.
> I hope the community finds this useful, and again I welcome any feedback
> or suggestions.
> Thanks,
> Deepak Eachempati
> HPCTools Group
> University of Houston
That sounds as if it does not support all of f2003. Is there a list of all the f2003 and f2008 features that are supported? (Some of us still have to avoid using f2003 features in 2012 because we test our programs with all the
compilers we have, and different compilers have implemented different things that were not in f95.)
On Sunday, October 14, 2012 4:45:54 PM UTC-5, jfh wrote:
> That sounds as if it does not support all of f2003. Is there a list of all
> the f2003 and f2008 features that are supported? (Some of us still have to
> avoid using f2003 features in 2012 because we test our programs with all the
> compilers we have, and different compilers have implemented different things
> that were not in f95.)
> --
> John Harper
Our group has implemented support for the coarray features that are in F2008. You can google "N1824" for a description of these features (Coarray in the next Fortran Standard, by John Reid).
The Fortan 2003 features that are supported in our compiler came from the PathScale compiler suite (version 3) via Open64 a number of years back. You can google "PathScale 3.2 user guide", and section 3.4 of that document will list the Fortran 2003 features which should be supported (though I have not myself verified each of them).
> I just wanted to notify those who are interested in a free compiler
> supporting Fortran coarrays that this is available in the OpenUH
> compiler. OpenUH is developed by the HPCTools group at the University
> of Houston. It is not a full Fortran 2008 implementation. It is based
> on the Open64 compiler, which support Fortran 95 and *some* Fortran
> 2003 features. We have implemented the coarray features that were
> added to Fortran 2008.
What's the plan to add "the rest" of f2003 features? I use as many as I can get away with based on current gfortran and intel releases.
So, while I'd love to play around with co-arrays, it's hard for me to get juiced about diagnosing what f2003 features have, or have not, been implemented in yet another compiler.
I'm not trying to put down your group's hard work, but I liken this sort of announcement (i.e. a general one to a broad community using, presumably, goodly portions of f2003 syntax in code) as trying to get people off the street to test a car with an advanced, efficient high-performance, petrol-sipping engine, .... but no wheels. :o)
I look forward to a f2003-compliant version of the OpenUH compiler.
cheers,
paulv
p.s. I am continually flummoxed as to why coarray implementation seems to take precedence over f2003 completion.
> I am interested in getting feedback from the community on all aspects
> of the implementation -- performance issues, features that may not be
> implemented correctly, ease of installation on your particular
> system, etc.
> A few notes about the implementation:
> (1) OpenUH should support all the coarray features that are in
> Fortran 2008. This includes coarrays of basic types and derived types
> (including coarrays with pointer/allocatable components), the inquiry
> and transformational functions (this_image, image_index, num_images,
> ucobound, lcobound), all the sync statements (sync all, sync images,
> sync memory), locks, critical sections, error stop, and the
> atomic_define/atomic_ref subroutines.
> (2) The runtime can be built against GASNet (1.18.2) or ARMCI (5.0).
> These are communication libraries designed to support PGAS
> implementations. If you are using the prebuilt compiler, then you
> need to download the separate caf-runtime source package and the
> build/install it into whereever you extracted the compiler. Both
> GASNet and ARMCI support a variety of networks or may operate in an
> SMP environment, so they provide good portability.
> (3) The compiler name is uhcaf. The launcher program is cafrun. E.g.
> # compile the program and links in the necessary runtime libraries: $
> uhcaf sample.f90 -o sample
> # run the executable with 4 images, more options available with
> --help $ cafrun -n 4 ./sample
> (4) Performance is something we're focused on improving. We leverage
> the bulk-communication capabilities available in GASNet/ARMCI for
> contiguous and strided accesses across images. Currently, for the
> program to benefit from this it must be written using the array
> assignment syntax. For example, this:
> x(:) = y(:)[p]
> will get you better performance than this:
> do i=lbound(x), ubound(x) x(i) = y(i)[p] end do
> Another performance limitation is the compiler doesn't yet generate
> non-blocking calls to help overlap your communication and
> computation, but this is something we're working on and hope to have
> ready by the end of this year.
> I hope the community finds this useful, and again I welcome any
> feedback or suggestions.
> Thanks, Deepak Eachempati HPCTools Group University of Houston
On Monday, October 15, 2012 7:37:25 AM UTC-5, Paul van Delst wrote:
> What's the plan to add "the rest" of f2003 features? I use as many as I
> can get away with based on current gfortran and intel releases.
> So, while I'd love to play around with co-arrays, it's hard for me to
> get juiced about diagnosing what f2003 features have, or have not, been
> implemented in yet another compiler.
> I'm not trying to put down your group's hard work, but I liken this sort
> of announcement (i.e. a general one to a broad community using,
> presumably, goodly portions of f2003 syntax in code) as trying to get
> people off the street to test a car with an advanced, efficient
> high-performance, petrol-sipping engine, .... but no wheels. :o)
> I look forward to a f2003-compliant version of the OpenUH compiler.
> cheers,
> paulv
> p.s. I am continually flummoxed as to why coarray implementation seems
> to take precedence over f2003 completion.
Thanks Paul, for your sharing your perspective, and I'm sure similar concerns would be shared by many others here. I agree that ideally we would have implemented coarrays on top of a F2003-compliant compiler so that programmers who wish to use modern Fortran don't have to worry about which features are being supported and which ones aren't.
The reason we have skipped ahead to implementing coarray features is that our ultimate agenda is more to explore the PGAS programming model provided by Coarray Fortran and implementation strategies for it, rather than to develop a fully compliant Fortran compiler. This is the work of only a few students in our group, so unfortunately resources are limited.
I would also like to point out that coarrays were initially proposed as an extension for Fortran 95, and the "Coarray Fortran" model is pretty much fully orthogonal to the features added in F2003. Though it is true that at least one notable Fortran user -- Bob Numrich -- has made a strong case for developing object-oriented coarray programs using a combination of F2003 and F2008 features.
For people that wish to try out the latest parallel processing features in the new standard (for instance, to augment their existing Fortran 95 codes), I hope OpenUH can be of use. If there are particular Fortran 2003 features that are highly important to the community, I would encourage people to send an email to openuh /at/ uh /dot/ edu, and we'll see what we can do to support it.
On Monday, October 15, 2012 9:13:39 AM UTC-5, Deepak Eachempati wrote:
> For people that wish to try out the latest parallel processing features in the new standard (for instance, to augment their existing Fortran 95 codes), I hope OpenUH can be of use. If there are particular Fortran 2003 features that are highly important to the community, I would encourage people to send an email to openuh /at/ uh /dot/ edu, and we'll see what we can do to support it.
Correction: that should have been openuh /at/ cs /dot/ uh /dot/ edu.
On Monday, October 15, 2012 9:13:39 AM UTC-5, Deepak Eachempati wrote:
> On Monday, October 15, 2012 7:37:25 AM UTC-5, Paul van Delst wrote:
> > What's the plan to add "the rest" of f2003 features? I use as many as I
> > can get away with based on current gfortran and intel releases.
> > So, while I'd love to play around with co-arrays, it's hard for me to
> > get juiced about diagnosing what f2003 features have, or have not, been
> > implemented in yet another compiler.
> > I'm not trying to put down your group's hard work, but I liken this sort
> > of announcement (i.e. a general one to a broad community using,
> > presumably, goodly portions of f2003 syntax in code) as trying to get
> > people off the street to test a car with an advanced, efficient
> > high-performance, petrol-sipping engine, .... but no wheels. :o)
> > I look forward to a f2003-compliant version of the OpenUH compiler.
> > cheers,
> > paulv
> > p.s. I am continually flummoxed as to why coarray implementation seems
> > to take precedence over f2003 completion.
> Thanks Paul, for your sharing your perspective, and I'm sure similar concerns would be shared by many others here. I agree that ideally we would have implemented coarrays on top of a F2003-compliant compiler so that programmers who wish to use modern Fortran don't have to worry about which features are being supported and which ones aren't.
> The reason we have skipped ahead to implementing coarray features is that our ultimate agenda is more to explore the PGAS programming model provided by Coarray Fortran and implementation strategies for it, rather than to develop a fully compliant Fortran compiler. This is the work of only a few students in our group, so unfortunately resources are limited.
> I would also like to point out that coarrays were initially proposed as an extension for Fortran 95, and the "Coarray Fortran" model is pretty much fully orthogonal to the features added in F2003. Though it is true that at least one notable Fortran user -- Bob Numrich -- has made a strong case for developing object-oriented coarray programs using a combination of F2003 and F2008 features.
> For people that wish to try out the latest parallel processing features in the new standard (for instance, to augment their existing Fortran 95 codes), I hope OpenUH can be of use. If there are particular Fortran 2003 features that are highly important to the community, I would encourage people to send an email to openuh /at/ uh /dot/ edu, and we'll see what we can do to support it.
> Regards,
> Deepak
This is exactly right. Fortran 2003 has nothing to do with Coarrays. It is useful for people who still limit their code to Fortran 95 (and there are lots of them) but want native parallelism, i.e., Fortran 95 + MPI users (and there are lots of them).
In article <e641386e-b2b9-4d03-8be0-3a780dcb359e@googlegroups.com>,
rusi_pathan <tabrez...@gmail.com> wrote:
> This is exactly right. Fortran 2003 has nothing to do with Coarrays. It is > useful for people who still limit their code to Fortran 95 (and there are > lots of them) but want native parallelism, i.e., Fortran 95 + MPI users (and > there are lots of them).
These same users would probably be interested in the IEEE numerics support and the the C interop features of f2003.
\"Vladimír Fuka <\"name.surname at <mffDOTcuniDOTcz"> wrote:
> Last time i tried, the most annoying for me was the missing STREAM access
> I/O.
Ouch. That would be a pain.
Even most f77 later vintage f77 compilers had functionality simillar to
stream, although they used various different spellings, which meant you
had to change the code when you moved from one compiler to another. But
the general functionality was simillar enough that at least the code
changes were simple "replace this with that" kinds of things.
I wonder whether the compiler in question might at least be in that
category - having a comparable funcionality, though not with the f2003
spelling.
-- Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
> This is exactly right. Fortran 2003 has nothing to do with Coarrays.
> It is useful for people who still limit their code to Fortran 95 (and
> there are lots of them) but want native parallelism, i.e., Fortran 95
> + MPI users (and there are lots of them).
True 'nuff, but it's still an artificial restriction on implementation choices for a developer.
Ron Shepard wrote:
> In article <e641386e-b2b9-4d03-8be0-3a780dcb359e@googlegroups.com>,
> rusi_pathan <tabrez...@gmail.com> wrote:
>> This is exactly right. Fortran 2003 has nothing to do with Coarrays. It
>> is useful for people who still limit their code to Fortran 95 (and there
>> are lots of them) but want native parallelism, i.e., Fortran 95 + MPI
>> users (and there are lots of them).
> These same users would probably be interested in the IEEE numerics
> support and the the C interop features of f2003.
> $.02 -Ron Shepard
I agree about IEEE numerics; the other f2003 feature I would like to see in all modern Fortran compilers is elemental intrinsics with logical, real or complex arguments being allowed in initialization expressions. At present g95 and gfortran do allow that but two other compilers I tried don't.
Deepak Eachempati <dreac...@gmail.com> wrote:
> Our group has implemented support for the coarray features that are in
> F2008. You can google "N1824" for a description of these features
> (Coarray in the next Fortran Standard, by John Reid).
I haven't been paying attention, so I downloaded and read this.
No collectives? I have to write my broadcast, allgather, scatterreduce?
No communicators? So I can not write a library that is used in a modular
way on a subset of processors?
Hmpf. I guess that's what you if you let a bunch of language theorists
ignore 20 years of parallel programming....
Please tell me I'm wrong.
Victor.
-- Victor Eijkhout -- eijkhout at tacc utexas edu
Victor Eijkhout wrote:
> Deepak Eachempati <dreac...@gmail.com> wrote:
>> Our group has implemented support for the coarray features that are in
>> F2008. You can google "N1824" for a description of these features
>> (Coarray in the next Fortran Standard, by John Reid).
> I haven't been paying attention, so I downloaded and read this.
> No collectives? I have to write my broadcast, allgather, scatterreduce?
> No communicators? So I can not write a library that is used in a modular
> way on a subset of processors?
Well, the idea was to release Fortran 2008 without either a long delay because of such additions or rushing with some definition.
Hence, it those got deferred to a Technical Report (now: Technical Specification, TS). As TS29113 on Further Interoperability of Fortran with C is now ready,* the committee is now working on the coarray TS. The plans for that TS are listed in the requirement document at ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1930.txt - I think that covers all what you missed.
The original Co-Array Fortran (see the paper Co-Array Fortran for Parallel Programming) did have language facilities for doing collective operations and also teams. There was some debate on what form this should take during the drafting of the Fortran 2008 standard, so those features didn't make it in. An official technical specification for additional coarray features is forthcoming which will very likely address this. I believe, in fact, that there is a working group meeting this week that is discussing this.
