Re: GRE: rogue comment: IEEE 754R and Reproducibility

[David Hough 754R work <754r@xxxxxxxxxxx>]

> My multicore collaborators think that, independent of floating point,
> in order to support the vast majority of programmers at the
> productivity level, the system
>   (1) must support debugging at the productivity layer, i.e. give the 
> same results
>        twice in a row from a.out, if necessary with a performance hit, 
> modulo the next point:
>   (2) should not add nondeterminism to an otherwise deterministically
>        constructed program at the "productivity layer", or at least require
>        an explicit setting of an "allow nondeterminism if it speeds up 
> up a lot"
>        switch
>
> My question about  IEEE 754R is whether there are any features that
> make this (modest) level of reproducibility hard to achieve? Clearly
> care must be taken to make sure operations like sum-reductions
> can occur in a deterministic order if desired.

I don't think 754R adds any surprises - those would come from language
semantics, particularly languages that leave lots of things 
implementation-defined.

There is one explicitly non-deterministic group of 754R operations - 
the scaled product reductions - that were retained in 754R when the
other reductions were thrown out, because the scaled product reductions
allow 754R to avoid ever mentioning scaled exponents in underflow and
overflow trap handlers, or the 7094 counting mode which accomplished the
same end.     754R provides a deterministic way of getting scaled product
reductions - write a loop with logb and scalb.