https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076
--- Comment #8 from Damian Rouson <damian at sourceryinstitute dot org> --- (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 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.
