(j3.2006) (SC22WG5.4122) [ukfortran] Parallel random numbers

[N.M. Maclaren]

On Oct 23 2009, Robert W. Numrich wrote:
>
>I agree with Aleks:
>
> > 1) All the sequencies are independent
> > 2) The same random number generator is used on each image (same seed,
> > same sequence).
> > 3) No restrictions on calling RANDOM_SEED and RANDOM_NUMBER ala ordering
> > of segments.
> > If the user wants to get different sequencies on different images, just
> > use different seeds. No quasi-independence or any such quality
> > guarantees---this is to be used in simple tests, debugging, student
> > codes, and for certain algorithms where the quality does not matter much
> > (for example, random alternation algorithms in linear-algebra algorithms
> > or even some PDE grid solvers)

There are two issues there.

    1) The first is that the examples are too optimistic; while the
quality doesn't matter much, the association is often SO bad that it
causes even those algorithms to give wrong answers.  Yes, I have seen
that, quite a few times.

    2) Are you really saying that the Fortran standard should REQUIRE a
known, deficient approach, of a nature that every expert in this area
regards as unacceptable?  That's not the Fortran I know.

>Making things "proceesor dependent", as suggested below, is a bad idea.
>If the programmer wants some special random sequence, he needs to generate
>it himself.  If he is serious about random numbers, even on a single
>processor, he should generate his own and not depend on some compiler
>generated sequence with no known properties.

That is the converse advice of what every expert has said since Knuth,
and all still say today.

While I agree that very few vendors have a clue about this area,
ordinary programmers have even less clue.  They are likely to pick up
some catastrophically bad generator from the net, because there are so
many more of them than competent ones out there.

> How could a shared sequence ever allow a programmer to bebug his code or 
> generate reproducible results? The member of the sequence obtained by any 
> particular image at run-time would be random, OK unless you are trying to 
> debug, but very expensive because it probably implies some sort of 
> lock/unlock of the sequence located somewhere, perhaps on image one.

Exactly the same way that people have been debugging programs since time
immemorial - which have any form of parallelism, asynchronicity or
time-dependence.  Fortran has NEVER guaranteed reproducibility of
realistic code even on identical hardware (see the expression evaluation
rules), and those of us with extensive experience of portability don't
expect it.

We really have been doing this for decades now, and this doesn't cause
more trouble than any serious optimisation of non-trivial expressions.
Seriously.

> Making this processor dependent makes it difficult (impossible?) to write 
> portable code. It also breaks the fundamnetal SPMD model that coarrays 
> are based on. Do we have any other intrinsic procedures, other than 
> sync's, that imply some global effect across images?

Other than much of I/O, memory allocation (i.e. failure handling),
GET_ENVIRONMENT_VARIABLE (together with using BIND(C) to call setenv)
and even SYSTEM_CLOCK, you mean?  And, yes, calling the last CAN have
global side-effects.

The point here is precisely that coarrays are based on a SPMD model, and
not a MIMD model.  There is a single program, and not a collection of
independent images - that's the MPI model.


Regards,
Nick Maclaren.