Coarray tutorial on github

[Thomas Koenig]

Hi,

since there does not appear to be a good coarray tutorial on
the Web, I thought it a good idea to start one. This is both
for people who want to start with it, but also maybe as a teaser
for people to show them how easy and clean a parallel programming
paradigm can actually be and which language to go for.

It is at https://github.com/tkoenig1/coarray-tutorial/ .
Corrections, extensions etc. higly welcome - I will then try
to figure out how to process a pull request (I'm rather new to
github :-)

[Gary Scott]

I hope someone will address use in GUI applications, how to prevent
multiple copies of the GUI from starting :(

[Thomas Koenig]

Gary Scott <garyl...@sbcglobal.net> schrieb:

Disclaimer: I do not know about the GUI you use, nor have I ever
done GUI programming from Fortran.

Having said that, there is currently a shared memory implementation
of coarrays for gfortran in the works. It still has very many
unimplemented features (teams being one of the foremost missing
features) but I don't see offhand why

if (this_image() == 1) call gui_init

or something like that should not work on that particular
implementation, unless the GUI in question plays strange tricks
with constructors.

[Gary Scott]

Typically GINO, but it's just a wrapper for a winmain with a special
entry point. I suspect that if I did the above this-image call, that
I'd simply end up with thousands of "gino not initialized" calls from
the other processes. :(

[steve kargl]

Seems like a good question for GINO support forum.

--
steve

[Gary Scott]

Doubt the answer is different than any program with a winmain and
message loop.

[Steve Lionel]

On 1/2/2021 11:03 AM, Gary Scott wrote:
> I hope someone will address use in GUI applications, how to prevent
> multiple copies of the GUI from starting :(

This really isn't any different from a console application. Standard
input is connected only to image 1. Each image has its own "standard
output", but the standard encourages implementations to "merge the
streams" and most do.

Most coarray applications treat image 1 as special and it's the one that
interacts with the user, collecting input and distributing work to the
other images. I don't see a GUI as any different here. As long as you
don't call the GUI routines in images other than 1, it shouldn't be a
problem. If your chosen GUI "automatically" starts something just by
being linked in, that's a problem.

--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

[مهدي شينون‎]

Off-topic:
Could you rebase coarray_native branch on master, so we can test it on MinGW-w64.

[Thomas Koenig]

مهدي شينون <chinoun...@gmail.com> schrieb:

> Could you rebase coarray_native branch on master, so we can test it on MinGW-w64.

Working.

However, the chances this currently working on MinGW are low.
The shared memory implementation currently uses mmap(), which
MinGW - to my knowledge - does not provide.

Somebody who knows more about Windows system programming than
the people currently working on this would have to provide a
reimplementation for Windows of the shared memory handling.

That might also need to be adjusted for Darwin, which apparently
has some limitations in that area which are not present in other
Unixoid systems.

Patches are highly welcome, by the way :-)

[Gary Scott]

On 1/2/2021 5:43 PM, Steve Lionel wrote:
> On 1/2/2021 11:03 AM, Gary Scott wrote:
>> I hope someone will address use in GUI applications, how to prevent
>> multiple copies of the GUI from starting :(
>
> This really isn't any different from a console application. Standard
> input is connected only to image 1. Each image has its own "standard
> output", but the standard encourages implementations to "merge the
> streams" and most do.
>
> Most coarray applications treat image 1 as special and it's the one that
> interacts with the user, collecting input and distributing work to the
> other images. I don't see a GUI as any different here. As long as you
> don't call the GUI routines in images other than 1, it shouldn't be a
> problem. If your chosen GUI "automatically" starts something just by
> being linked in, that's a problem.
>

It starts 4 GUI windows if I enable coarrays in a subroutine that only
contains "calcs". The application substantially does nothing in the
program main other than to "start/initialize the gui" as is normal for a
windowing program...essentially it calls a winmain with an
initialization section hidden within the init subroutine. I could try
moving that initialization one level lower in the procedure call
structure, but that would be fairly massive change to the automatic
recovery and restart process I have set up for out of memory and other
abort conditions...yikes

[Steve Lionel]

On 1/3/2021 2:36 PM, Gary Scott wrote:
> It starts 4 GUI windows if I enable coarrays in a subroutine that only
> contains "calcs".  The application substantially does nothing in the
> program main other than to "start/initialize the gui" as is normal for a
> windowing program...essentially it calls a winmain with an
> initialization section hidden within the init subroutine.

The problem as I see it here is that a Windows application with a
WinMain entry point (/subsystem:windows) doesn't have a Fortran main
program. The coarray implementations I am familiar with hook coarray
initialization into the main program, though I suppose there are other
mechanisms possible. Perhaps the implementation you are using allows you
to call the initialization API yourself. If so, you could do that from
WinMain and then simply not create the windows and messaging loop except
on image 1.

[Gary Scott]

On 1/4/2021 8:27 AM, Steve Lionel wrote:
> On 1/3/2021 2:36 PM, Gary Scott wrote:
>> It starts 4 GUI windows if I enable coarrays in a subroutine that only
>> contains "calcs".  The application substantially does nothing in the
>> program main other than to "start/initialize the gui" as is normal for
>> a windowing program...essentially it calls a winmain with an
>> initialization section hidden within the init subroutine.
>
> The problem as I see it here is that a Windows application with a
> WinMain entry point (/subsystem:windows) doesn't have a Fortran main
> program. The coarray implementations I am familiar with hook coarray
> initialization into the main program, though I suppose there are other
> mechanisms possible. Perhaps the implementation you are using allows you
> to call the initialization API yourself. If so, you could do that from
> WinMain and then simply not create the windows and messaging loop except
> on image 1.
>
>

Ah ha...the compiler is IVF. So I think what you're saying is that my
application doesn't really have a MAIN section since I've defined an
alternate entry point (for the GUI). Yet IVF still starts 4 separate
GUIs as if coarray processing is in force. Where might it have hooked
the coarray initialization?

[spectrum]

Isn't a GUI program so-called "event-driven"?
https://en.wikipedia.org/wiki/Event-driven_programming
Then I guess coarrays (or SPMD) are practically not so convenient to use
for GUI programs... (because almost all the program code
may need to be modified).

[Steve Lionel]

On 1/4/2021 11:53 AM, Gary Scott wrote:

> Ah ha...the compiler is IVF.  So I think what you're saying is that my
> application doesn't really have a MAIN section since I've defined an
> alternate entry point (for the GUI).  Yet IVF still starts 4 separate
> GUIs as if coarray processing is in force.  Where might it have hooked
> the coarray initialization?

The "launcher" is run from the main program. If you don't have a main
program, the launcher doesn't run. Typically, a "windowing" program with
a WinMain entry point doesn't have a main program. To be honest, I'm
unsure how that main program gets invoked here - I know it is typically
called from the ifort run-time library, but I thought that required
linking in a specific console library. Nevertheless, I see the behavior
you describe when I add a dummy main program (just an END statement).

I tried some experiments to see if I could figure a way around this, but
did not succeed. I suggest you contact Intel support (if your license
includes support), or ask in the Intel Fortran forum, if there is a way
to do your own coarray initialization call. ifort supports a
/qcoarray:single option (not in the VS interface) that omits the
"launcher", requiring you to do your own mpirun.

[Gary Scott]

On 1/4/2021 2:52 PM, Steve Lionel wrote:
> On 1/4/2021 11:53 AM, Gary Scott wrote:
>
>> Ah ha...the compiler is IVF.  So I think what you're saying is that my
>> application doesn't really have a MAIN section since I've defined an
>> alternate entry point (for the GUI).  Yet IVF still starts 4 separate
>> GUIs as if coarray processing is in force.  Where might it have hooked
>> the coarray initialization?
>
> The "launcher" is run from the main program. If you don't have a main
> program, the launcher doesn't run. Typically, a "windowing" program with
> a WinMain entry point doesn't have a main program. To be honest, I'm
> unsure how that main program gets invoked here - I know it is typically
> called from the ifort run-time library, but I thought that required
> linking in a specific console library. Nevertheless, I see the behavior
> you describe when I add a dummy main program (just an END statement).
>
> I tried some experiments to see if I could figure a way around this, but
> did not succeed. I suggest you contact Intel support (if your license
> includes support), or ask in the Intel Fortran forum, if there is a way
> to do your own coarray initialization call. ifort supports a
> /qcoarray:single option (not in the VS interface) that omits the
> "launcher", requiring you to do your own mpirun.
>

Thanks. At least I'm not COMPLETELY crazy :) I had assumed that there
was always a MAIN and that a winmain or alternate entry point as for
GINO was just a subroutine/function called from within that MAIN section
internally (not that it replaced it).