Giving something new time to mature before making it the default is always a great policy. My suggestion is aspirational. I’m describing a dream that I hope can be the ultimate goal. There’s no need to rush into implementing my proposed vision.
D On Tue, Jun 24, 2025 at 23:25 Andre Vehreschild <ve...@gmx.de> wrote: > Hi Damian, hi Steve, > > enabling coarray-support by default has implications we need to consider. > The > memory footprint of a coarray enabled program is larger than the one of a > non-coarray one. This is simply because the coarray token needs to be > stored > somewhere. > > Furthermore, I just yesterday figured, that with -fcoarray=single the > space for > the token was allocated. I.e. every data structure, that could possibly be > stored in a coarray and had allocatable components in it, wasted another 8 > byte > for an unused pointer. > > So when we default to having coarray support enabled, some work needs to be > done, to remove such inefficiencies. Given there are only a few developers, > that work on coarrays, this may take some time. > > What we can of course do, is to switch on the coarray mode, when we detect > the > first coarray construct and no longer need the user to do it. I hope this > does > not have to many implications and causes only a hand full of bugs. > > For the time being, I propose to first give the new coarray implementation > some > time to mature and test. There will be bugs, because nobody is perfect. > > @Steve caf_shmem does not use MPI. It is a shared memory, single node, > multi > process approach. Just to prevent any misunderstanding. > > Thanks for all the testing. > > Regards, > Andre > > On Tue, 24 Jun 2025 11:13:52 -0700 > Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > > > Damian, > > > > I submitted a patch a long time ago to make -fcoarray=single the > > default behavior. The patch made -fcoarray=none a NOP. With > > inclusion of a shmem implementation of the runtime parts, this > > might be the way to go. I'll leave that decision to Andre, Thomas, > > and Nicolas. > > > > I believe that the gfortran contributors have not considered > > coarray as an optional add-on. The problem for gfortran is > > that it runs on dozens of CPUs and dozens upon dozens of > > operating systems. The few gfortran contributors simply cannot > > ensure that opencoarray+mpich or opencoarray+openmpi runs on > > all of the possible combinations of hardware and OS's. Andre > > has hinted that he expects some rough edges on non-linux system. > > I'll find out this weekend when I give his patch a spin on > > FreeBSD. Hopefully, a windows10/11 user can test the patch. > > > > > -- > Andre Vehreschild * Email: vehre ad gmx dot de >
