Re: Coarray shared memory testing
On 7/19/25 10:59 AM, Toon Moene wrote: 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 = 1, VERSTEP = 100, FCLEN = 3600, TIMSTEP = 240 integer, parameter :: DNX = 1000, DNY = 1500, DNZ = 100, BDSIZE = 4, HORSTEP = 1, 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, Yes, this is why we need additional testers. For those who need some guidance to the test branch: $ git clone git://gcc.gnu.org/git/gcc.git $ cd gcc $ git checkout remotes/origin/devel/gfortran-test $ git switch -c gfortran-test Configure and build as usual is a separate directory not the source directory. I am going to be out on travel for about a week. When I return, maybe I can do testing on other machines. If anyone is aware of open code that would be a good example of testing many features of coarray fortran, please advise. Thanks Toon. Regards, Jerry
Re: Coarray shared memory testing
Am 19.07.25 um 18:32 schrieb Jerry D: I am ready to approve this. Can anyone second this. I have grave concerns. At the last (to me an Nicolas) known state, before he was ousted from the project, there were known race conditions, which can cause freezing and/or data corruption. I believe these have not been addressed, neither tested nor by inspection. Best regards Thomas
Re: Coarray shared memory testing
On 7/19/25 2:26 PM, Thomas Koenig wrote: I wrote: I have grave concerns. At the last (to me an Nicolas) known state, before he was ousted from the project, there were known race conditions, which can cause freezing and/or data corruption. I believe these have not been addressed, neither tested nor by inspection. Maybe a word of explanation. What I would like to see are tests like program memain integer :: i,j do j=0,5 ! To be adjusted do i=1,10**j sync all end do print *,"Finished 10**", j end do end program run on a few hundred cores in parallel. Or counting (again, untested): program memain use, interinsic :: iso_fortran_env, only : lock_type type(lock_type), codimension[*] :: lck integer, codimension(*) :: count integer :: i, j, s do j=0,5 ! To be adjusted, dunno how long this runs if (this_image() == 1) count = 0 sync all do i=1,10**j lock (lck[1]) count[1] = count[1] + 1 unlock (lck[1]) end do sync all if (this_image() == 1) then print *,"Expected: ",10**j*num_images(), "Found: ", count end if sync all end do end program plus similar torture cases for SYNC IMAGES, CRITICAL and END CRITICAL, allocatable coarrays etc. If this testing is not done (and resulting bugs fixed), there is an extremely high chance that race conditions and other problems such as memory leaks are introduced. Best regards Thomas Thank you, this helps me to understand better. I will strive to achieve this kind of testing. Suggestions from others as code samples would be greatly appreciated. We should be able to build up a suite of tests to use for validation. Best Regards, Jerry
Re: Coarray shared memory testing
I wrote: I have grave concerns. At the last (to me an Nicolas) known state, before he was ousted from the project, there were known race conditions, which can cause freezing and/or data corruption. I believe these have not been addressed, neither tested nor by inspection. Maybe a word of explanation. What I would like to see are tests like program memain integer :: i,j do j=0,5 ! To be adjusted do i=1,10**j sync all end do print *,"Finished 10**", j end do end program run on a few hundred cores in parallel. Or counting (again, untested): program memain use, interinsic :: iso_fortran_env, only : lock_type type(lock_type), codimension[*] :: lck integer, codimension(*) :: count integer :: i, j, s do j=0,5 ! To be adjusted, dunno how long this runs if (this_image() == 1) count = 0 sync all do i=1,10**j lock (lck[1]) count[1] = count[1] + 1 unlock (lck[1]) end do sync all if (this_image() == 1) then print *,"Expected: ",10**j*num_images(), "Found: ", count end if sync all end do end program plus similar torture cases for SYNC IMAGES, CRITICAL and END CRITICAL, allocatable coarrays etc. If this testing is not done (and resulting bugs fixed), there is an extremely high chance that race conditions and other problems such as memory leaks are introduced. Best regards Thomas
Re: Questions on `scan` Intrinsic Implementation (For Fortran 2023 `split` procedure)
On Sun, Jul 20, 2025 at 12:39:00AM +0800, Yuao Ma wrote: > On 7/18/2025 11:43 PM, Yuao Ma wrote: > > I noticed that hex(16128084538487209988) evaluates to > > 0xdfd27774, and it looks like the higher bits weren't being > > zeroed out as expected. After I explicitly added pos = > > convert(gfc_charlen_type_node, pos); for type conversion, the test case > > started working perfectly. > > I'm sorry, but just adding a cast doesn't solve the issue. Even if we change > the pointer type, we may not be able to alter the memory layout of the input > parameter. Therefore, when accessing the value with a wide type pointer, we > still may not obtain the desired result.. > > Not sure how to handle this in/out parameter in this case. Maybe the > string_split function in libgfortran should be aware of the integer kind? > No. It should no be aware of integer kind. You need to deal with this is fortran FE in trans-intrinsics.cc with appropriate convessations of Fortran INTEGERs to C int and back. -- Steve
Re: Questions on `scan` Intrinsic Implementation (For Fortran 2023 `split` procedure)
On 7/18/2025 11:43 PM, Yuao Ma wrote: I noticed that hex(16128084538487209988) evaluates to 0xdfd27774, and it looks like the higher bits weren't being zeroed out as expected. After I explicitly added pos = convert(gfc_charlen_type_node, pos); for type conversion, the test case started working perfectly. I'm sorry, but just adding a cast doesn't solve the issue. Even if we change the pointer type, we may not be able to alter the memory layout of the input parameter. Therefore, when accessing the value with a wide type pointer, we still may not obtain the desired result.. Not sure how to handle this in/out parameter in this case. Maybe the string_split function in libgfortran should be aware of the integer kind? Yuao
Re: Coarray shared memory testing
On 7/17/25 9:37 PM, Jerry D wrote: I have created a new gfortran-test branch on gcc here. origin/devel/gfortran-test This has the patches applied as needed to do the testing I have done. When Andre's patches are approved I will revert and rebase this so we can test the next set of major changes. I have done this to simplify the process of testing for those who would like to just check out the branch and build it. Regards, Jerry On 7/17/25 5:44 PM, Jerry D wrote: On 7/16/25 7:13 AM, Andre Vehreschild wrote: Hi Jerry, I am back on track. --- snip --- After some back and forth with Andre I finally understand the discrepancies I was having here. Andre has an OpenCoarrays branch being used to update OpenCoarrays to sync with changes to gfortran-16. This branch is here: https://github.com/sourceryinstitute/OpenCoarrays/tree/vehre/issue-779-form-team The changes being made to implement the newer TEAM features and shared mem result in a change to the gfortran interface for -fcoarray=lib libraries. The first four patches of the patch set implement these changes. The last two add the new shared memory library. First I applied the gfortran patches and did a clean build of the compiler. Second I rebuild OpenCoarrays with the issue-779-form-team branch using the patched gfortran compiler. All OpenCoarrays tests pass. Here is the results of the random-weather example: $ cat ~/bin/set-shared export FC=/home/jerry/dev/usrav/bin/gfortran export CC=/home/jerry/dev/usrav/bin/gcc export GFORTRAN_NUM_IMAGES=8 export LD_LIBRARY_PATH=/home/jerry/dev/usrav/lib64/:/home/jerry/dev/usrav/lib/ [aside: FC and CC must be set correctly so the OpenCoarrays uses the correct gfortran] $ . set-shared $ $FC -v Using built-in specs. COLLECT_GCC=/home/jerry/dev/usrav/bin/gfortran COLLECT_LTO_WRAPPER=/home/jerry/dev/usrav/libexec/gcc/x86_64-pc-linux- gnu/16.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gccav/configure --prefix=/home/jerry/dev/usrav --enable- languages=c,c++,fortran --enable-libgomp --disable-bootstrap Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 16.0.0 20250717 (experimental) (GCC) [aside: No need to install as long as one uses the newly built caf and cafrun.] $ ../opencoarrays-clean/bin/caf random-weather.f90 $ time ../opencoarrays-clean/bin/cafrun -np 8 ./a.out . . . real 0m26.533s user 3m2.067s sys 2m35.954s $ $FC -fcoarray=lib random-weather.f90 -lcaf_shmem $ time ./a.out . . . real 0m0.055s user 0m0.279s sys 0m0.102s With this setup I can test with other examples. I have the necessary gfortran patches gathered here and will get these out to the gfortran-test branch I created earlier. Regards, Jerry I expanded on Toon's random_weather.f90 test using: !integer, parameter :: DNX = 72, DNY = 70, DNZ = 30, BDSIZE = 4, HORSTEP = 1, VERSTEP = 100, FCLEN = 3600, TIMSTEP = 240 integer, parameter :: DNX = 1000, DNY = 1500, DNZ = 100, BDSIZE = 4, HORSTEP = 1, 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 ... real1m12.935s user11m50.423s sys 5m57.636s mpich: $ ../opencoarrays-clean/bin/caf random-weather.f90 $ time ../opencoarrays-clean/bin/cafrun -np 20 ./a.out ... real164m48.280s user2492m58.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. Regards, Jerry
Re: Coarray shared memory testing
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 = 1, VERSTEP = 100, FCLEN = 3600, TIMSTEP = 240 integer, parameter :: DNX = 1000, DNY = 1500, DNZ = 100, BDSIZE = 4, HORSTEP = 1, 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
