https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076
--- Comment #9 from Nicolas Koenig <koenigni at gcc dot gnu.org> --- Sorry for the late reply, there was a sad incidence with my laptop and ice cream :D (In reply to Damian Rouson from comment #8) > (In reply to Nicolas Koenig from comment #7) > > > I actually opted to use multiprocessing with shared memory (shm_open() & co) > > instead of multithreading, since it will be much easier and faster with > > static variables, of which gfortran makes extensive use. Also, it greatly > > simplifies interoperability with OpenMP. > > This sounds like a great choice. I have no prior familiarity with > shm_open(), > but I very much like the idea of simplifying interoperability with OpenMP. > > > The only real downsides I can think of are slower spinup times... > > It will be interesting to compare the performance with MPI. I also wonder if > this would also someday provide for a hybrid implementation wherein > shm_open() > is used within a node and MPI is used across nodes, e.g., maybe images within > a TEAM could use shm_open() to communicate, while any communication between > TEAMs could use MPI. > I think that would be ideal. The only problem with this would be that we would have to maintain 3 implementations, which would be quite work intensive. > > > > > I actually think it would be best not to turn it into a separate library but > > instead integrate it into libgfortran. > > I agree. > > > This way, it will not be necessary to > > install a seperate library and thereby make it easier for people to start > > using coarrays. Therefore, it would make sense to use the libgfortran > > descriptors. > > > > > At the moment, sync_all() is called after image creation. > > I think that will suffice.
