Re: Mixing reproducible and non-reproducible code
Nick, Dan, Michel
On 2 Dec 2012, at 11:55, N.M. Maclaren wrote:
> On Dec 2 2012, Dan Zuras Intervals wrote:
>>> From: Michel Hack <mhack@xxxxxxx>
>>> There may be more at stake than representation issues. Reproducible mode
>>> may affect global properties, such as forcing single-threaded execution.
>>> So what do we expect to happen when modes are mixed?
>>> (1) The interface module could force single-threaded execution while the
>>> reproducible-mode component is running. Is that generally feasible?
>>> (2) The reproducibility properties of the reproducible-mode component
>>> could be voided, as basic assumptions of that mode don't pertain.
>
> Gug. Oops. Yes, that needs resolving. I can see how it would be
> handled in practice, but specifying it is trickier. Essentially, as
> I am sure you were thinking, the two codes would be compiled separately.
Nick makes valid points about determinism being (un)related to correctness, etc., but I think he is not quite fair. If a bug is identified, it is much easier to locate relevant faults if running in reproducible mode. And it is much easier to prove a block of code correct, formally or informally, if only one thread is involved. I would value optional reproducibility, as a debugging aid.
I think we can say what a block of reproducible code (better said: the block being run in reproducible-mode) *is* in an abstract sense. To specify it in a particular language is harder. It involves forbidding various constructs that allow the block's variables to be changed by a back door. I thought, surely Fortran has addressed this by the PURE attribute of procedures, which imposes compiler-checkable restrictions on constructs.
But studying PURE in Metcalf & Reid "Fortran 90/95 explained", it seemed that PURE is intended to prevent a procedure *affecting* the outside environment during its execution. Whereas we want to prevent a block *being affected* by the outside environment during its execution. E.g., cannot a pure procedure P access COMMON, or module variables, that can be accessed during its execution by code Q executing in parallel? It seems P is forbidden to change such variables, but Q could change them and thus make P's execution non-reproducible? Fortran experts please clarify.
On Michel's points above:
(1) What do you mean by "feasible" here? I'm no OS expert, but can't any operating system make it happen by putting P into a critical section, suspending any other code that can affect P's variables? The effect on performance could be disastrous of course.
(2) This seems mainly an issue of how a language specifies, and a compiler enforces, reproducibility properties. Is that our business?
This topic is important, but IMO most of it is beyond P1788's remit. Can we make a modest change to the existing wording, to say what's needed without committing the standard to anything?
John Pryce