Re: Justifying Optimization

srikanth <srikanth@cup.hp.com>
21 Jan 2003 00:09:31 -0500

          From comp.compilers

Related articles
Justifying Optimization mike.dillon@lmco.com (MICHAEL DILLON) (2003-01-17)
Re: Justifying Optimization joachim_d@gmx.de (Joachim Durchholz) (2003-01-20)
Re: Justifying Optimization srikanth@cup.hp.com (srikanth) (2003-01-21)
Re: Justifying Optimization christian.bau@cbau.freeserve.co.uk (Christian Bau) (2003-01-21)
Re: Justifying Optimization vbdis@aol.com (2003-01-21)
Re: Justifying Optimization jgd@cix.co.uk (2003-01-21)
Re: Justifying Optimization touati@prism.uvsq.fr (Sid TOUATI) (2003-01-25)
Re: Justifying Optimization ONeillCJ@logica.com (Conor O'Neill) (2003-01-25)
Re: Justifying Optimization jvorbrueggen@mediasec.de (Jan C. =?iso-8859-1?Q?Vorbr=FCggen?=) (2003-01-25)
[17 later articles]
| List of all articles for this month |

From: srikanth <srikanth@cup.hp.com>
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

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.


Post a followup to this message

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