Re: Justifying Optimization

Christian Bau <christian.bau@cbau.freeserve.co.uk> writes


>I have used development systems where debugging compiler optimised
>code was significantly more difficult. Not just debugging, but single
>stepping through code which is the most basic test one should
>do. Write the code, compile it, then single step through it to make
>sure your code doesn't do anything _really_ stupid. Optimising also
>can cost considerable compile time.


I disagree that single stepping through code is the most basic test
you can do. I only ever revert to single stepping as a very last
resort when hunting for bugs.


I also agree with other respondents that you if you are shipping
optimised code, then obviously you should develop and test that same
code.


However, I'm also coming more to the view that it is not necessary to
optimise _everything_. Typically, your numerical sections would
benefit greatly from optimisations, but much of your program logic has
such random access patterns that a compiler can't do much with it.


Use a profiler to determine which are the important parts, and only
turn on the optimiser for those parts. And of course they will have
their own test harnesses, won't they (:-), so they can be validated in
isolation... Don't rely on the programmer's intuition to choose the
sections to optimise; it will often be wrong :-(.




To answer the original poster's questions, my feeling is that the real
points to consider are these:


a) Early optimisers did have a tendency to be buggy. I feel that the
more modern ones are much less buggy, aided by the fact that people
tend to use then turned on as a matter of course nowadays, so most of
the bugs are shaken out.


b) Some compilers produce fairly primitive code when the optimiser is
turned off. They don't, for example, use registers, etc. This means
that un-optimised code can be very inefficient (if looked at the
assembly output). GCC seems to suffer like this. However, as I said
above, if this is code is rarely executed, that may not matter, but it
can bloat code size.


--
Conor O'Neill, Bristol, UK. Not speaking for my employer.

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