(j3.2006) F03/0084, was Re: Interp letter ballot #25

[Van Snyder]

On Mon, 2012-05-14 at 17:33 -0500, Bill Long wrote:
> 
> On 5/14/12 5:20 PM, Van Snyder wrote:
> > On Mon, 2012-05-14 at 12:07 -0600, Keith Bierman wrote:
> >> But we digress. As Malcom aptly notes, the interp at hand really
> >> shouldn't drag intervals back into the spotlight.
> >
> > Right.  It really has to do with the range of applicability of
> > "mathematical equivalence" between different statements, for purposes of
> > optimization.
> >
> > If we want to get this right, and avoid further controversy and
> > confusion, we should specify that mathematical equivalence does not
> > apply to expressions that might be evaluated with different rounding
> > modes in effect, that involve operands whose values might have changed
> > (including but not limited to those that have the VOLATILE attribute),
> > or that are evaluated in different segments.
> >
> > This could be specified in the answer to the interpretation -- without
> > any edits, and therefore no new features, and no new
> > "optimisation-disabling" effects.
> 
> And yet your list of suggestions already includes some 
> optimization-disabling effects.

There wouldn't be any new optimization-disabling effects because there
would be no edits.

Anyway, sniveling about "optimization-disabling effects" is a grotesque
exaggeration.  The only places and times where optimizations would be
disabled are very rare, and almost always exactly what the author of the
program wants and expects.

Exactly which optimizations would be disabled, which of those are
desirable, how frequently do they appear (not counting in carefully
contrived SPEC benchmarks), and what effect would that have on overall
program run time?  As Knuth said, "premature optimization is the root of
all evil."

> Why even venture into this mine field?

Because the answer to F03/0084 is contrary to the expectations of all of
my colleagues, whose interests I am expected to represent to the Fortran
committees.  Their priorities are "get it right, get it out, get it
fast," especially after the very expensive Mars Climate Orbiter loss,
not the old SGI priorities of "get it out, get it fast, get it right,"
with the last one frequently not happening at all.

Anything that interferes with "get it right" has much more severe impact
than something that might be conjectured, without any significant
practical evidence, to have measurable effect on "get it fast."

> The outcome would almost certainly be even more interps.

This is pure speculation.

> Cheers,
> Bill
> 
> >
> > On Mon, 2012-05-14 at 12:16 +0900, Malcolm Cohen wrote:
> >
> >>> If "mathematically equivalent" includes "ignore IEEE rounding mode
> >>> changes"
> >>
> >> No it does not.
> >>
> >>> then we might as well remove the rounding mode facilities from
> >>> the IEEE modules, since the result of this interpretation is "they don't
> >>> actually work anyway."
> >>
> >> They do work, they apply to the actual operations being executed.
> >
> >> The rounding mode applies to the actual operations being
> >> executed.  The point being that after the permitted mathematical
> >> transformations, there are no operations being executed.
> >
> > The point of my comment, which was apparently not well understood, was
> > that the interpretation incorrectly argues to allow the transformation,
> > resulting in no operations being executed, thereby effectively
> > subverting the program's obvious desire to carry out the calculations,
> > and to do so with different rounding modes.
> >
> > Setting a rounding mode means that evaluating<expr>  is really the
> > mathematical operation<expr>  + f(<expr>), where "f" is different for
> > each rounding mode.  Arguing that since f(<expr>) doesn't appear in the
> > text, it doesn't exist, and therefore doesn't count for purposes of
> > "mathematidal equivalence," is arguing that rounding mode setting
> > changes can be ignored in conformant programs.
> >
> >> Note that the rounding mode is inherited, so IEEE_SET_ROUNDING_MODE is
> >> frequently not visible.
> >
> > It's either visible, or invoked in an impure procedure.  Is it allowed
> > to exploit "mathematical equivalence" for optimizations spanning
> > invocations of impure procedures?
> >
> >> That means that any optimisation-disabling effect that you apparently
> >> want it to have would potentially need to be applied to the
> >> entire program.
> >
> > Grotesquely exaggerated nonsense.  It's not the rounding mode that
> > causes problems for optimization, it's the rounding mode _CHANGE_!
> > Unless a program consists of 50% rounding-mode changes, there are no
> > significant "optimisation-disabling" effects.
> >
> > Do we contemplate allowing simplifications based upon mathematical
> > equivalence spanning coarray synchronization points?  I think not.  How
> > is prohibiting it from spanning changes of rounding modes any different,
> > or any more of an "optimisation-disabling" effect?
> >
> >> My comment was simply showing one way of disabling unwanted optimisations, a way
> >> that works fairly locally....  A single assignment
> >> to and reading from a VOLATILE variable is often cheaper than a whole external
> >> procedure invocation (the more traditional way of road-blocking the optimiser).
> >
> > There's nothing in 5.3.19 that prohibits exploiting mathematical
> > equivalence to subvert the effect most readers expect of VOLATILE.
> > Applying the VOLATILE attribute is not, therefore, a way of "blocking
> > unwanted optimisations."  Assuming X, Y, Z1, and Z2 have the VOLATILE
> > attribute, if one writes
> >
> > Z1 = X * Y
> > Z2 = X * Y
> > print *, Z1 - Z2
> >
> > a conformant processor is free to exploit mathematical equivalence to
> > eliminate the  assignments and the subtraction, and always print zero.
> >
> > I can already hear the chorus of "But, but, but... 5.3.19p1 says that an
> > object with the VOLATILE attribute "may be redefined, defined, or become
> > undefined, by means not specified by the program."  That's a
> > _computational_ difference, not a _mathematical_ difference.
> >
> >
> > _______________________________________________
> > J3 mailing list
> > J3 at j3-fortran.org
> > http://j3-fortran.org/mailman/listinfo/j3
>