This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [4.7, RFC, Fortran] Coarray: Moving towards real parallelization


On 03/04/2011 05:57 PM, Ralf Wildenhues wrote:
MPI_Init (argc, argv);
If you're relying on MPI2 anyway, I suggest you try to not limit your
users to not use MPI themselves.  So please use MPI_Initialized, and
don't finalize if the library isn't responsible.
Well, the current implementation relies on an early initialization
by the front end, the compiler generates a main program, which
initializes the library. Thus, there is no chance for the user to
call MPI earlier.
Ouch.  That then also means that the user will not be able to use MPI
herself in the program
for them, MPI_Init first thing in main is the
documented way to initialize MPI, but it will invoke undefined behavior
with above setup.

Well, if I look in the yellow book also states that one should use MPI_Initialized to check whether it is already initialized. If they want to combine MPI with coarrays they have to be prepared that for coarrays also MPI might be used as backend communication library. That's always the problem as soon as one mixes parallelization schemes (OpenMP, pthread, MPI, GASNet, ARMCI/GA, shmem, ...) or different programming languages (C, UPC, C++, Ada, Pascal, go, ...): one needs to be careful, may need to add additional checks, and possibly some function calls to initialize libraries.


Besides, I do not see any possibility to prevent the issue, except using a different communication library than MPI. The MPI initialization can happen any time in the program, e.g. deep in some linked library - or it might never happen. Thus, it makes sense to initialize the coarray library early - which is before the actual user code starts.

Note further that the front end does not know which coarray communication library is linked. It can be the MPI one, it can be a stub one (effectively single image), or it could be pthread or some other library such as GASNet or ARMCI, which might sometimes also use MPI as backend.

However, in order to make it easier to use the library with a non-Fortran main program, I have added a MPI_Initialized check and I will later document in gfortran.texi how to initialize the library in that case.

However, one should think of having a coarray
program, where the main program is not a Fortran program. In that
case, the parallelization library could be called later. However,
one then runs into issues like initializing the library. I think one
has to think carefully about that - but supporting coarrays with a
non-Fortran main program causes several subtle issues.
Could be; but I think you should aim for something like that in the end,
it would be significantly more user-friendly.

I do not see any difference to the status quo, except for documenting the library function and for adding an MPI_Initialized. That won't be userfriendly but mixed-language programming is rarely user friendly.


Tobias

PS: Actually, one could delay the initialization of the library to the first use, but as one does not know when it happened and as an MPI_Init could come (hidden via a function call) at any point, one would effectively need to add before every communication a check whether the library is initialized, which would kill the performance and would still not help if the first coarray communication comes before the the MPI_Init ...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]