Re: Justifying Optimization

Jan C. Vorbrüggen wrote:
>
>>I agree with Michael's colleagues that performance is rarely a
>>reason to turn optimization on.
>
> Tell that to the people buying the largest computers and using
> petacycles for their work.


These are the rare exceptions (at least in terms of manpower spent on
programming).


  > At the other end of the scale, in an
> embedded system some optimization can make the difference between what
> chip to use, saving a few cents per item, and making the difference
> between bliss and misery (cf. Dickens).


Agreed. Industrial programming is a different case entirely. But,
again, it's a niche market in terms on man-years spent. Most
programmer time is invested into commercial applications targetted for
Windows and nothing else (sad as this state of affairs is). In that
area, it makes sense to run the debug-mode code, simply to cut down on
the effort for testing.


Additional testing with the optimizer turned on will just find a lot
of bugs that were never relevant in debug code - why fix them?
Customers don't care about them, fixing them just runs the risk of
introducing other errors, and customers want that the software vendor
invests his time into new features (or in fixing the more obvious bugs
and misfeatures), not in making the software beautiful.


Things are quite different in the original poster's scenario. He's
compiling with different compilers on different platforms; making the
software conform to a specific compiler with a specific set of options
is not an option for him, he'll have to make his software conform to the
language specification.


> I even disagree that one can debug without optimization. There are
> enough cases were you have to leave your program running for
> substantial time until you get to the point where debugging can
> start (watchpoints, conditional breakpoints, and all that). If that
> time increases from a few minutes to an hour, you've just lost a lot
> of productivity. You _should_ insist on a development system that
> allows you to mix optimized and non-optimized code.


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. Under these circumstances, I couldn't
care less about the factor of 2 that compiler optimization usually
gives.


What's much more important is that I have very fine systematic control
over which assertions are checked in what modules. I can specify
assertion checking per module, per class, or per function; each
specification says "no assertions", "just precondition checking",
"postcondition checking", "class invariant checking", "assert
instructions in the middle of function bodies". This is important:
precondition checking is usually cheap, postcondition checking takes
up somewhat more time, class invariants are really expensive (because
they are checked on *every* call - an innocent-looking "file.open
implies file.name /= Void" can take up reasonable amounts of time if
it's checked on every file read and write, particularly if file.open
calls system functions - but then class invariant checking is roughly
equivalent to a watchpoint, you're warned at the earliest opportunity
when an object starts to break down).


Regards,
Joachim

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