|Justifying Optimization email@example.com (MICHAEL DILLON) (2003-01-17)|
|Re: Justifying Optimization firstname.lastname@example.org (Joachim Durchholz) (2003-01-20)|
|Re: Justifying Optimization email@example.com (srikanth) (2003-01-21)|
|Re: Justifying Optimization firstname.lastname@example.org (Christian Bau) (2003-01-21)|
|Re: Justifying Optimization email@example.com (2003-01-21)|
|Re: Justifying Optimization firstname.lastname@example.org (2003-01-21)|
|Re: Justifying Optimization email@example.com (Sid TOUATI) (2003-01-25)|
|Re: Justifying Optimization ONeillCJ@logica.com (Conor O'Neill) (2003-01-25)|
|Re: Justifying Optimization firstname.lastname@example.org (Jan C. =?iso-8859-1?Q?Vorbr=FCggen?=) (2003-01-25)|
|[17 later articles]|
|Date:||21 Jan 2003 00:09:31 -0500|
|Organization:||SSO-IT, Hewlett-Packard Co.|
|Posted-Date:||21 Jan 2003 00:09:31 EST|
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
> 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.
Return to the
Search the comp.compilers archives again.