Re: Justifying Optimization

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

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