Re: Justifying Optimization

srikanth <>
21 Jan 2003 00:09:31 -0500

          From comp.compilers

Related articles
Justifying Optimization (MICHAEL DILLON) (2003-01-17)
Re: Justifying Optimization (Joachim Durchholz) (2003-01-20)
Re: Justifying Optimization (srikanth) (2003-01-21)
Re: Justifying Optimization (Christian Bau) (2003-01-21)
Re: Justifying Optimization (2003-01-21)
Re: Justifying Optimization (2003-01-21)
Re: Justifying Optimization (Sid TOUATI) (2003-01-25)
Re: Justifying Optimization (Conor O'Neill) (2003-01-25)
Re: Justifying Optimization (Jan C. =?iso-8859-1?Q?Vorbr=FCggen?=) (2003-01-25)
[17 later articles]
| List of all articles for this month |

From: srikanth <>
Newsgroups: comp.compilers
Date: 21 Jan 2003 00:09:31 -0500
Organization: SSO-IT, Hewlett-Packard Co.
References: 03-01-088
Keywords: optimize
Posted-Date: 21 Jan 2003 00:09:31 EST



> 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.


Post a followup to this message

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