Re: Justifying Optimization

MICHAEL DILLON wrote:


[...]


> The other argument, that optimization produces errors, is the one that
> is new to me. While I've not had any personal indication of this, I
> don't have any hard facts.
>
> So with that as a long intro, I'd love to get some opinions on this?
> Is there any substantiated data that says optimized code is more prone
> to errors? Is there a generally accepted guideline in the community
> that says when you should/should-not optimize? Is there a general
> level of compiler technology so that I can say that I'd gain ~x% by
> optimizing?
>
> I really consider this a general question, but in case it helps, our
> development will be with both Windows 2000, using .NET, and Sun
> Solaris using Forte. Both predominantly C++.
>
> Thanks, Al
> [I didn't know that anyone was still having this argument. While it's
> true that optimizers sometimes have bugs, it's far more common that
> they reveal bugs in application code that does stuff that the language
> spec forbids, e.g., depending on the relative order of evaluation of
> subexpressions in the same expression. If you care whether your code
> works, build test suites and test the optimized application before you
> ship it. -John]


We do hear this argument from developers working on floating point
intensive code. The optimized program may produce results that differ
from the unoptimized program by a very "small" amount. If all the test
suite is does is a textual diff against masters generated by an
unoptimized run, then many spurious failures may show up, forcing the
developers to eyeball the results.


HP compilers provide an options +Ofltacc which inhibits any expression
reordering optimizations that may result in numerical differences in
the floating point results and allows all other optimizations to occur
: presumably other compilers do too.


Srikanth.

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