Re: Justifying Optimization

Christian Bau wrote:


> 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.


If you're at that stage of development, optimizing sure enough doesn't
make much sense.


> And I have seen cases where code that worked fine without
> optimisation stopped working with optimisation. Often the real error
> was undefined behavior in C code; the same problems would happen if
> you just switched to a different compiler. Fact is that the code
> stopped working with optimisation.


I'll resist commenting on this item.


> Developing with optimisation switched off and then trying to ship
> code with optimisation switched on is asking for trouble.


Agreed.


> Developing with optimisation switched on will make development take
> longer, because compile times are longer and debugging is harder.


Developing with optimisation switched off will make development take
longer, because run times until you get to the debug points are
longer. Tried configuring the usual make files for mixing optimized
and non-optimized code?


> or it spends time by just being stupid (in my recent experience,
> most performance gains I achieved were by changing code that did
> just stupid things), or it spends time in accessing memory and any
> optimisations your C compiler does don't have any effect at all.


A good compiler - even a C compiler! - nowadays does much more than
just optimize arithmetic. See what the Sun C compiler did to CFP2000
art for an (admittedly extreme) example - whole-program restructuring
I'd call it. And not all the world is in C, you know.


> Ask yourself how much you will gain.


That's good advice for sure.


> Now the psychological effect: If you overrule the wishes of your
> developers, you will feel good and they will feel bad. Developers
> who feel bad develop bad code. Many of them know better how to
> develop than you do. Most of them believe they know better how to
> develop than you do. You are not paid for feeling good, you are paid
> for making the developers feel good so that they produce good code.


The general idea is good. I'd change the advice to say, ask them to
prove their position to you, experimentally. Agree on the experiment
and its design as well as the analysis procedure and figures of merit,
do the experiment, and decide based on the outcome.


> If your developers are worth what you pay them, then they are worth
> listening to. You have been developing years ago, they do it
> know. Times change.


Such basic things don't change much even in decades, in my experience.
I'm continuously amazed at how things I learned and did twenty years
ago are still applicable and very up-to-date now. Plus ca change...


Jan

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