On 7/19/25 18:32, Jerry D wrote:
I expanded on Toon's random_weather.f90 test using:
!integer, parameter :: DNX = 72, DNY = 70, DNZ = 30, BDSIZE = 4, HORSTEP =
10000, VERSTEP = 100, FCLEN = 3600, TIMSTEP = 240
integer, parameter :: DNX = 1000, DNY = 1500, DNZ = 100, BDSIZE = 4,
HORSTEP =
10000, VERSTEP = 100, FCLEN = 3600, TIMSTEP = 240
For the default problem size and using 20 images on my 8 core 16 "thread"
machine.
shmem:
$ export GFORTRAN_NUM_IMAGES=20
$ $FC -fcoarray=lib random-weather.f90 -lcaf_shmem
$ time ./a.out
...
real 1m12.935s
user 11m50.423s
sys 5m57.636s
mpich:
$ ../opencoarrays-clean/bin/caf random-weather.f90
$ time ../opencoarrays-clean/bin/cafrun -np 20 ./a.out
...
real 164m48.280s
user 2492m58.342s
sys 121m22.190s
I believe that the benefits of this outweigh any concerns and it is
quite useful for particular problem sets and can for people developing
and testing coarray applications before deploying to big iron
machines if needed.
These results are using the gfortran-test branch in the gcc git
repository.
I am ready to approve this. Can anyone second this.
This test branch is certainly useful for further testing. However, I
should emphasize that my "mock weather forecasting code" is nice to
confirm this kind of speed-up, it isn't a full test of the coarray
implementation. It uses only a small subset of all coarray features, and
it certainly isn't a good test of the possible ways to run into
deadlocks ...
Note that Thomas Koenig has written about this before:
https://gcc.gnu.org/pipermail/fortran/2025-June/062361.html.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
