Re: Justifying Optimization

vbdis@aol.com (VBDis)
6 Feb 2003 00:07:29 -0500

          From comp.compilers

Related articles
[12 earlier articles]
Re: Justifying Optimization lars@bearnip.com (2003-01-26)
Re: Justifying Optimization cgweav@aol.com (2003-01-29)
Re: Justifying Optimization tmk@netvision.net.il (2003-01-30)
Re: Justifying Optimization lex@cc.gatech.edu (Lex Spoon) (2003-02-05)
Re: Justifying Optimization bobduff@shell01.TheWorld.com (Robert A Duff) (2003-02-05)
Re: Justifying Optimization vbdis@aol.com (2003-02-06)
Re: Justifying Optimization vbdis@aol.com (2003-02-06)
Re: Justifying Optimization joachim_d@gmx.de (Joachim Durchholz) (2003-02-11)
Re: Justifying Optimization joachim_d@gmx.de (Joachim Durchholz) (2003-02-11)
Re: Justifying Optimization joachim_d@gmx.de (Joachim Durchholz) (2003-02-11)
Re: Justifying Optimization bhurt@spnz.org (2003-02-11)
Re: Justifying Optimization nde_plume@ziplip.com (2003-02-11)
Re: Justifying Optimization cgweav@aol.com (2003-02-11)
[1 later articles]
| List of all articles for this month |

From: vbdis@aol.com (VBDis)
Newsgroups: comp.compilers
Date: 6 Feb 2003 00:07:29 -0500
Organization: AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com
References: 03-01-158
Keywords: practice, debug
Posted-Date: 06 Feb 2003 00:07:29 EST

Joachim Durchholz <joachim_d@gmx.de> schreibt:


>Additional testing with the optimizer turned on will just find a lot
>of bugs that were never relevant in debug code - why fix them?


I really cannot understand this argument. A compiler can analyse a
program in the same way, regardless of non/optimized code
generation. If a compiler only does extensive checks for optimized
code only, then it is not appropriate for program development.


>>You _should_ insist on a development system that
>> allows you to mix optimized and non-optimized code.


Agreed.


>My situation is a bit different. In my environment, switching
>assertions on or off can change performance by a factor of 10, 100, or
>even 1000, depending on the amount of assertion checking that some
>piece of code is laced with.


IMO you should spend more time or money for proofing the correctness
of your code. Assertions only can reveal /that/ something has gone
wrong, but will not normally reveal the place /where/ something has
gone wrong.


IMO it /is/ possible to write correct code, which deserves no runtime
checks, and the overall cost of such code will be lower than of
"traditional" code, when only the time for debugging and the cost of
errors at the customer sites are taken into account. Only few
companies can afford to ship banana software, which ripens at the
customer sites, when the income of such companies is based on the
sales of new releases, not on the confidence of the customers into the
quality of the software. Testing software may be required all the
time, but testing cannot replace software engineering.


DoDi


Post a followup to this message

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