gfortran documentation fix: replace getpid() with THIS_IMAGE() in init_random_seed()

[Janne Blomqvist]

On Tue, May 17, 2016 at 10:35 AM, Damian Rouson
<damian@sourceryinstitute.org> wrote:
> I probably should have made clear that the motivation was that the Cray compiler doesn't support the getpid() extension so my primary question is how would you suggest  to replace this extension in the interest of portability?  Any suggestions in that direction would be greatly appreciated.

AFAIK the Fortran standard doesn't provide any mechanism to
distinguish one instance of a program from another, hence why the
example code in the manual uses getpid(). Or well, if you care only
about targets with ASLR, perhaps you could get by with adapting

program aslrtest
  use iso_c_binding, only: c_loc
  integer, target :: i
  print *, c_loc(i)
end program aslrtest

Then again, if we're in the game of limiting targets, most targets of
interest except Windows provide /dev/urandom, so if you don't care
about Windows you can forget about the entire "else" branch in that
example.

Still, I think getpid() is better than the above two approaches for
the GFortran manual.

>
> Damian
>
> Sent from my iPhone
>
>> On May 16, 2016, at 11:39 PM, Janne Blomqvist <blomqvist.janne@gmail.com> wrote:
>>
>> On Tue, May 17, 2016 at 2:30 AM, Damian Rouson
>> <damian@sourceryinstitute.org> wrote:
>>> All,
>>>
>>> Would THIS_IMAGE() be a reasonable, standard-conforming replacement for
>>> the gfortran extension “getpid()” in the following documentation page?
>>>
>>> https://gcc.gnu.org/onlinedocs/gfortran/RANDOM_005fSEED.html
>>>
>>> From the comment a few lines above the call, it seems the primary motivation
>>> for generating a process ID (PID) is for each parallel instance to receive a
>>> unique integer result.  In my very limited testing with gfortran/OpenCoarrays
>>> in shared memory on Linux and OS X, the getpid() result differs from that of
>>> THIS_IMAGE() by an offset that is constant across all images.
>>>
>>> THIS_IMAGE() might be superior in that it guarantees each image a
>>> unique result even in distributed memory, which I assume getpid() does
>>> not guarantee.  If others agree, I’ll submit a documentation patch.  I will
>>> also add a comment suggesting that the user replace THIS_IMAGE()
>>> with the appropriate procedure for the user’s chosen parallelization
>>> technology (e.g., MPI process rank or OpenMP thread number).
>>
>> I can't really make heads or tails of the description at
>> https://gcc.gnu.org/onlinedocs/gfortran/THIS_005fIMAGE.html, but from
>> looking at the example and some other examples I found with google, it
>> seems that THIS_IMAGE() is mostly equivalent to MPI_Comm_Rank() in the
>> MPI world? That is, it's an integer in the range [1, NUM_IMAGES()]?
>>
>> If so, then replacing getpid() with THIS_IMAGE() might not be such a
>> good idea, what if a user launches several instances of a serial
>> program on the same machine (which I think is a vastly more common
>> occurrence than somebody actually using co-arrays)? Then THIS_IMAGE()
>> will return 1 for all processes?
>>
>> If you're worried about getpid() returning the same value on multiple
>> machines in the distributed memory case (unlikely, but entirely
>> possible), you could amend the example to additionally XOR
>> THIS_IMAGE() in addition to the current time and getpid(), instead of
>> replacing the usage of getpid().
>>
>> As for threads or OpenMP, currently the GFortran random number
>> generator is a single serial generator protected by a mutex, it
>> doesn't make sense to initialize it separately in each thread. I
>> submitted a RFC patch a while ago to fix this (
>> https://gcc.gnu.org/ml/fortran/2015-12/msg00119.html ), I was planning
>> to dust if off and submit it properly for gcc 7 at some point, but
>> we'll see if I find the time..
>> --
>> Janne Blomqvist
>



-- 
Janne Blomqvist