Re: Floating point constant question

|> In my opinion, it depends on the programmer what accuracy is acceptable
|> (and hence what result are valid). Luckily, SPEC agrees. SPEC actually
|> allows deviation in results for SPEC89/92. The below was gleaned from
|> SPECfp92 benchmark Makefiles:


I suspect that these numbers have nothing to do with reliability, and
everything to do defining "correctness" so that the various vendors can
generate "correct" results. SPEC is just a benchmark suite chosen by a
bunch of hardware vendors.


|> The trend seems to be in the opposite direction. For example, when
|> compiling with -O3, IBM's compilers will perform mathematically equivalent
|> but numerically different transformations (I don't know if recipricol is
|> one of them).


I suspect that they are making use of the fused-multiply-add, which
computes


      result = input1 * input2 + input3


with only a single rounding, and not two as you would get if you used a
pair of instructions. This, at least, is more accurate.


In general, I think this trend is nuts (yes, I'm aware that reordering can
occur in Fortran as long as it does not disobey parentheses). I can
tolerate accuracy-enhancing optimizations (such as use of fused-madd, or
replacing div-imprecise with mult-precise-reciprocal) under the control of
a flag, but if you are trying to ensure that your application will exhibit
no bugs in the field, then you do not want to monkey with its behavior in
any way, even if you are making it "better".


In addition, verification of a compiler is made more difficult by these
sorts of things. No longer is there a single right answer -- now there is
a range of correct answers. Testing (to the same degree of confidence)
becomes much more expensive. This is especially true if you put other
behavior-"improving" optimizations under the control of the "-O11" flag.


Sorry if I'm sounding pedantic today, but sometimes I think people go a
little nuts for speed. I'd like to see people go a little overboard on
the side of predictability and correctness, just for grins.


David Chase, speaking for myself
Thinking Machines Corp.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.